[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: User-reserved element in byte code vectors
From: |
Stefan Monnier |
Subject: |
Re: User-reserved element in byte code vectors |
Date: |
02 May 2004 17:07:07 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
>> I thought you already had it implemented.
> I'm using another way which I sketched in a message a few days ago.
OK, so I understood it right. My argument is that my way is better than
your current way.
In your current way (at least what I can tell from your sketch), calling
a closure involves really two function calls (you first call the wrapper
which then calls the bytecode with the extra environment argument, which is
the massaging I was talking about).
Constructing a closure in your scheme involves creating the wrapper which
boils down to constructing one new byte-compiled-object as well as one new
"constants" vector which holds the static environment, the real
byte-compiled code and maybe one or two more constants.
I.e. one byte-compiled-object and one vector.
I.e. the downside of my approach (constructing one byte-compiled-object
plus one constants vector) doesn't seem nearly as bad when seen in
this light. Admittedly my constants vector will generally be larger so
your closure-construction is still usually more efficient, but
only profiling can tell if the difference is significant.
>> Well, there are two questions:
>> - how best to implement closures, given the current Emacs C code.
>> - how best to implement closures, assuming we get to change the C code.
>> I'm talking about the first question. Miles's work is within the context
>> of the second.
> I'm interested in both.
I'm also interested in both, but we can't say "answer 1 to question 1 sucks
because answer 2 to question 2 is better".
To get back to the original question, I now don't see how you can usefully
put the static environment in slot 7 without making changes to the C code,
so there's no point deciding it's reserved for use by elisp packages.
As for the rest of the meta-data you might want to put in
byte-compiled-objects, maybe we should dedicate one of the slots (maybe the
7th or 8th) for an alist where people can put whatever they want.
Stefan
- Function vectors: +funvec-20030518-0-c.patch, (continued)
Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/02
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/02
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/02
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/02
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/02
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/02
- Re: User-reserved element in byte code vectors,
Stefan Monnier <=
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/03
Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/02