[racket] on the arity of the composition of procedures with different arities
Eli: are you saying that you think this is _not_ a bug?
(I think Racket has firmly positioned itself in the "primitive
operations in the language do the right thing or signal errors" camp,
so a performance-based concern like this seems quite out of
character.)
Robby
On Fri, Nov 9, 2012 at 10:40 AM, Eli Barzilay <eli at barzilay.org> wrote:
> I just measured the overhead again, to see if things changed. The
> attached file has the exact implementation of the compose functions,
> and another copy with the proper reduction and renaming. For the
> correct function I'm getting ~5x slowdown from the current code, which
> in turn is 20x slower than just using a lambda. This is big enough to
> justify a comment saying something like "don't use this if you care
> about speed", which kind of makes the whole point of the function
> redundant.
>
> Notes:
>
> 1. Yes, the docs should say that already, but still I consider jumping
> to a slowdown of two orders of magnitude as a major problem.
>
> 2. I'm not talking about a theoretical point here -- I *have* seen
> `compose' used in tight loops, and I have personally written
> explicit lambdas in code where I really should have just used it.
>
> 3. There are definitely other cases where things like `apply' are used
> in a way that doesn't preserve arity, so it's not like this is an
> exceptional problem (or a new one).
>
> 4. I'll shut up now.
>
>
> 20 minutes ago, Robby Findler wrote:
>> 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.
>
>
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
>