Re: User-reserved element in byte code vectors

[Lars Brinkhoff]

Stefan Monnier <address@hidden> writes:
> > > 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.

Yes, I agree.

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

Yes, and maybe some consing of the &rest argument to the wrapper?

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

Right.  For reference, my wrapper function looks like this:
#[(&rest args) "<8 bytes>" [env args <environment> apply <function>] 3]

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

Sorry, I didn't mean to imply that anything sucks.

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

Not as an environment slot for current Emacs Lisp code, no.

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

That would be nice.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/