Re: Function vectors: +funvec-20030516-0-c.patch

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> It adds yet-anoter-form-of-function.  I.e. it makes function calls yet
>> a tiny bit slower, forces placed that look inside functions (like
>> describe-function) to deal with yet-another-case, ...
> Well, as I said, the cost is `negligible' -- it's essentially another EQ
> test, a branch, and some adds, in a non-fast-path location.  It shares 99%
> of its code with normal curry.

Well, "negligible" is always "w.r.t" something, typically the upside.
You conveniently ignored `describe-function' and `defadvice'...

> Probably the biggest cost is actually the docstring.
>> From what I can tell, rcurry will simply never be used.
> Er, I just said that I'd used it in the past; don't you believe me?

You said in Dylan.  Dylan is not Elisp.  And if someday somewhere someone
uses rcurry, I still don't find this very compeling since an elisp
implementation on top of existing functionality would work just as well.

> It's good to think about cost/benefit tradeoffs, but there's a point at
> which it can become silly.

Think about what happens to the byte-code optimizer when it inlines
a function: will it treat rcurry specially as well?  What about mixed-curry
when we add it (which would also be a negligible addition, after all)?

Let's only add things we need.  For one I don't believe that we even need
"curry" as such.  What we need is a cheap&fast way to implement closures.
"curry" is a way to do that, so it makes sense to add it in the C core.
"rcurry" provides no such useful functionality and can thus just as well be
implemented in elisp.  If we later on see that it indeed should deserve
a more efficient treatment, then we can always put it back in C.


        Stefan