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