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

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!