[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Function vectors: +funvec-20030516-0-c.patch
From: |
Miles Bader |
Subject: |
Re: Function vectors: +funvec-20030516-0-c.patch |
Date: |
Mon, 17 May 2004 18:21:51 -0400 |
User-agent: |
Mutt/1.3.28i |
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"
- Re: User-reserved element in byte code vectors, (continued)
- 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, 2004/05/17
- Re: Function vectors: +funvec-20030516-0-c.patch,
Miles Bader <=
- 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
Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/02