Re: User-reserved element in byte code vectors

[Miles Bader <miles@gnu.org>]

On Thu, May 06, 2004 at 10:24:18AM -0400, Stefan Monnier wrote:
> >    (curry '+ 1 2 3)
> >    => #[curry + 1 2 3]
...
> But of course it will break some elisp code that expects a byte-compiled-p
> object to have a particular shape (typically code that wants to get at the
> docstring, or the arglist, or the interactive spec).

I think such code will be (1) extremely rare, and (2) the sort of very
specialized thing that will not be done by externally-maintained user
packages.  So it should be no problem to look for and fix it ahead of time
(and once fixed, such code will kosher for future uses of byte-vectors in
this manner, with different first-element tags).

> I'm still not sure I understand what it would be used for.
> 
> Is that how you construct closures in your lexbind branch?

Yes (well, of course there I currently still use normal vectors, but I'll
obviously change to this new representation if it can go into the trunk).

> I thought you used extra arguments in byte-compiled-objects for that.

No; the extra arg in byte-compiled-objects is a flag telling eval to use
lexical binding for the arguments -- it's a static part of the
byte-code-object, and only applies to byte-code-objects, so it makes sense to
put it there.

[Remember closures are created dynamically, so all the extra futzing around
required to use an `extra argument in byte-compiled-objects' would be pretty
annoying.  See my earlier reply to Lars for a list of reasons...]

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.