Re: User-reserved element in byte code vectors

[Lars Brinkhoff]

Miles Bader <address@hidden> writes:
> On Mon, May 03, 2004 at 10:03:24AM -0400, Richard Stallman wrote:
> > All else being equal, I would rather use bytecode objects than
> > vectors for something funcallable.
> If you just don't like vectors being funcallable, then of course
> (e.g.) another special-purpose vector type could be used instead.
> However it would be nice if it were printable, and if users could
> set/access the elements easily; by using standard vectors, these
> things come for free.

It occurred to me that there already is funcallable vector-like type
with all those nice properties: the bytecode type.  If funcall was
changed (and I don't know if this is acceptable) to "curry" in all
bytecode elements after the 6th, that would work as well as Miles's
funcallable vectors.

E.g. Ffuncall could be changed to something like:

        if (COMPILEDP (fun))
          {
            int size = XVECTOR (fun)->size & PSEUDOVECTOR_SIZE_MASK;
            if (size <= 6)
              /* The usual case, as before.  */
              val = funcall_lambda (fun, numargs, args + 1);
            else
              {
                /* This is adapted from Miles's funcallable vectors.  */
                int num_curried_args = size - 6;
                internal_args =
                  (Lisp_Object *) alloca ((num_curried_args + numargs)
                                          * sizeof (Lisp_Object));
                
                /* Curried args are first in the new arg vector.  */
                bcopy (XVECTOR (fun)->contents, internal_args,
                       num_curried_args * sizeof (Lisp_Object));

                /* User args are last.  */
                bcopy (args + 1, internal_args + num_curried_args,
                       numargs * sizeof (Lisp_Object));
                
                val = funcall_lambda (fun, num_curried_args + numargs,
                                      internal_args);
              }
          }

This would be an incompatible change, but I don't think anyone relies
on the old behaviour.

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