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

[Miles Bader <miles@gnu.org>]

On Mon, May 17, 2004 at 12:09:32PM -0400, Stefan Monnier wrote:
> 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.

Fair enough; nobody likes rcurry, so I'll take it out.

BTW, this brings back a question you asked in private email a loooong time
ago (which I never answered): why are the two different representations for
compiled and interpreted closures in my lexical-binding implementation.

My (unsent) answer then was because the lexical binding implementations for
the interpreter is `weird', so needs special treatment to implement closures
-- the interpreter depends on funcall &c `resetting' the interpreter's
lexical-binding stack at appropriate times to avoid bindings being visible in
called functions.

My old implementation adds special code to Feval, Ffuncall, etc., to do this,
and when it sees a `closure' special form (instead instead of a `lambda'),
explicitly uses the intepreted closure's environment instead of setting the
interpreter lexical-binding stack to nil.

Working on this closure stuff, I now realize I can get rid of the special
code and instead use a #[] closure that calls a special
`call-interpreted-closure' internal function which just passes its args to
the guts of funcall, bypassing the normal `resetting' mechanism.  Essentially
the same thing, but it gets rid of special-case code in central places like
Ffuncall &c.

-Miles
-- 
"1971 pickup truck; will trade for guns"