[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Function vectors: +funvec-20030516-0-c.patch
From: |
Stefan Monnier |
Subject: |
Re: Function vectors: +funvec-20030516-0-c.patch |
Date: |
17 May 2004 12:09:32 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
>> 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
- Re: User-reserved element in byte code vectors, (continued)
- Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/23
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/22
- Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/18
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/16
- Message not available
- Message not available
- Function vectors: +funvec-20030516-0-c.patch, Miles Bader, 2004/05/16
- Function vectors: +funvec-20030516-1-c.patch, Miles Bader, 2004/05/16
- Re: Function vectors: +funvec-20030516-0-c.patch, Stefan Monnier, 2004/05/16
- Re: Function vectors: +funvec-20030516-0-c.patch, Miles Bader, 2004/05/16
- Re: Function vectors: +funvec-20030516-0-c.patch, Stefan Monnier, 2004/05/16
- Re: Function vectors: +funvec-20030516-0-c.patch, Miles Bader, 2004/05/16
- Re: Function vectors: +funvec-20030516-0-c.patch,
Stefan Monnier <=
- Re: Function vectors: +funvec-20030516-0-c.patch, Miles Bader, 2004/05/17
- Re: Function vectors: +funvec-20030516-0-c.patch, Stefan Monnier, 2004/05/18
- Re: Function vectors: +funvec-20030516-0-c.patch, Richard Stallman, 2004/05/17
- Re: Function vectors: +funvec-20030516-0-c.patch, Richard Stallman, 2004/05/17
- Re: Function vectors: +funvec-20030516-0-c.patch, Miles Bader, 2004/05/17
- Re: Function vectors: +funvec-20030516-0-c.patch, Richard Stallman, 2004/05/18
- Function vectors: +funvec-20030518-0-c.patch, Miles Bader, 2004/05/18
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/06
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/06
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/06