Re: User-reserved element in byte code vectors

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

>> 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