Re: User-reserved element in byte code vectors

[Stefan Monnier]

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

I haven't noticed anybody complain about it until now.  It'll work just
fine, although a bit slower, but a lot of Elisp code is not speed-sensitive
and if you care about speed and don't have rcurry, you can almost always
reorganize your code a bit such that your arguments come in the right order.

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

Not even necessary.  We can easily do

  (defmacro rcurry (f &rest args)
    `(curry rcurry-helper f ,@args))

and make a rcurry-helper subroutine.  And for Richard's permutation of
args, we can also do it that way with curry-reorg auxiliary function.

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

There are many ways to provide the proposed behaviors, but since we haven't
seen them needed, we have no clue which implementation would be best.

I think paying one extra word for each and every closure ever created from
now on, just because of the remote possibility that someone will want
something like rcurry and will want it to be really efficient and that
someone will not prefer some other implementation....
Are you people serious?


        Stefan