[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: |
Mon, 17 May 2004 18:06:12 -0400 |
User-agent: |
Mutt/1.3.28i |
On Mon, May 17, 2004 at 12:30:05PM -0400, Stefan Monnier wrote:
> > My idea is that it would say where to fit the new args around the old
> > args. For instance, you might want to curry args 2 and 3. This would
> > be easy if the first slot has a list saying where the curried args go.
> > For instance, a list of integers saying which positions to use
> > the curried args in.
>
> We already have a very simple way to express such things:
I think the case where using `lambda' becomes annoying is when you have a
variable-length arglist, which with lambda would require using &rest or
something, and so do lots of run-time consing.
It's probably true that at this point it's over-engineering, but perhaps
Richard's stance of just leaving a single nil slot available for future
exploration is reasonable. A single vector slot is not very expensive.
On the other hand, I'm not sure it's really better than omitting the slot
now, and later adding a `super-curry' funvec-kind that has the slot -- code
that cares about funvec layout would have to be amended to deal with non-nil
values of the slot anyay, so making it understand `super-curry' isn't much
different, right? If Stefan's intuition proves right, and `super-curry'
never gets added, then it will represent a small savings.
Oh bother, I'm not sure what to do...
[Well, actually since it's Richard's decision in the end, and he currently
wants the slot, I'll add it unless you guys convince him it's a bad idea...]
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
- Re: User-reserved element in byte code vectors, (continued)
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/14
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/14
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/14
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/14
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/14
- Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/15
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/15
- Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/17
- Re: User-reserved element in byte code vectors, Lars Brinkhoff, 2004/05/17
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/17
- Re: User-reserved element in byte code vectors,
Miles Bader <=
- Re: User-reserved element in byte code vectors, David Kastrup, 2004/05/17
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/17
- Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/18
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/18
- Re: User-reserved element in byte code vectors, Stefan Monnier, 2004/05/18
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/18
- Re: User-reserved element in byte code vectors, David Kastrup, 2004/05/19
- Re: User-reserved element in byte code vectors, Miles Bader, 2004/05/19
- Re: User-reserved element in byte code vectors, Richard Stallman, 2004/05/19
- Function vectors: +funvec-20030520-0-c.patch, Miles Bader, 2004/05/19