emacs-devel
[Top][All Lists]
Advanced

[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: 06 May 2004 12:55:49 +0900

Richard Stallman <address@hidden> writes:
> Instead we could dedicate slot 7 to a vector of curried args.  That
> would not interfere with other uses of other slots.

I'm a bit confused by how Lars is suggesting that byte-code vectors be
used for currying.  From the Ffuncall code-snipped he posted, I gather
that he was saying that the curried args be just a way to attach magic
arguments to an existing byte-code vector.

However currying is usually used as a way of _wrapping_ an existing
function.  Morever, it should (1) support interpreted functions as well,
and (2) be efficient (no consing when calling a curried function, and
ideally, little additional overhead compared to calling a non-curried
function).

Using his code, one could use byte-code objects with the traditional
first 6-slots containing a special `currying trampoline' function, but
really I'm not sure the point -- doing that seems to have lots of
disadvantages:

  (1) It would require consing for each call in many cases

  (2) It would incur extra time overhead when calling the curried
       function (executing the trampoline function),

  (3) Constructing curried functions would be a lot more heavyweight,
      because the various magic byte-code bits have to be constructed
      (_especially_ if you tried to do analysis to avoid some consing
      overhead by not using &rest when possible).

  (4) If you're going to construct special trampoline functions anyway,
      why not just stick the curried arguments into the byte-code
      constant vector in the first place?

So while I can see that maybe using a non-standard vector type like
byte-code vectors could be a good idea, the current suggestions don't
seem very good.

How about the following:  If a byte-code vector's first element is
`curry', treat the remaining elements the same way my current (normal
vector) currying implementation works, otherwise treat it as a normal
byte-code function.  Since the first element in a normal byte-code
object is an arg-list, it should never be an atom, so there shouldn't be
any conflict between the two uses.

So for example:

   (curry '+ 1 2 3)
   => #[curry + 1 2 3]

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]