[racket] on the arity of the composition of procedures with different arities

I think the right approach is to make the function behave correctly
first and then find the places to optimize second.

In this case, using procedure-reduce-arity (or something else with the
same effect) is not merely "nice" but, IMO, necessary. That is, we
have procedure-arity in our PL and our primitives/core libraries
should respect that.

Robby

On Fri, Nov 9, 2012 at 10:04 AM, Eli Barzilay <eli at barzilay.org> wrote:
> On Tue, Aug 7, 2012 at 10:46 PM, Erik Dominikus
> <erik.dominikus71 at gmail.com> wrote:
>> I had this conversation with DrRacket 5.2:
>> [...]
>
> On August 7th, Robby Findler wrote:
>> Looks like a bug in compose1 (and compose) to me.
>
> The source of both `compose' and `compose1' has the place where this
> would be fixed -- see the "here" below:
>
>              [(composed)
>               ;; FIXME: would be nice to use `procedure-rename',
>               ;; `procedure-reduce-arity' and `procedure-reduce-keyword-arity'
>               ;; in the places marked below, but they currently add a
>               ;; significant overhead.
>               (if (eq? 1 arity)
>                 (lambda (x) (app f (g x)))
>                 (case-lambda          ; <--- here
>                   [(x)   (app f (g x))]
>                   [(x y) (app f (g x y))]
>                   [args  (app f (apply g args))]))]
>
> The reason I chose to avoid the overhead for getting a precise arity
> is that I think that people expect function composition to be pretty
> fast.  TBH, I'd even go to the point of defining it as a macro so that
> simple uses like ((compose1 f g) X) expand to an explicit `lambda'
> which would then be optimized away.
>
>
> (This is also re PR 13003, which resulted from the above; CCed bugs.)
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!