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 <e...@barzilay.org> wrote: > On Tue, Aug 7, 2012 at 10:46 PM, Erik Dominikus > <erik.dominiku...@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! ____________________ Racket Users list: http://lists.racket-lang.org/users
