Re: User-reserved element in byte code vectors

[Lars Brinkhoff <lars@nocrew.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> From your examples, I get the impression that other than the
> closure's environment you only need meta-data which can just as well
> be put in an alist, so you just need 2 extra slots: one for the
> closure and one for the extra slot.  Is that right?

So far, that would be quite fine by me, yes.  However, I still haven't
implemented all aspects of Common Lisp, e.g. funcallable instances and
generic functions, so I don't yet know if there would be more data I
would like to be in the byte code vector.

> I'd argue that the closure's enviornment should be put as the first
> element in the constants-vector rather than in a separate slot in
> the byte code object: it makes closure construction slower and more
> clostly, but it makes the function call faster (it's just a normal
> function call and you can access the closure's vars directly from
> the byte code without explicitly passing them as an extra argument).

Yes, that would be nice.  What I do right now is actually conceptually
like

        (defun make-closure (fn env)
          (byte-compile
            `(lambda (&rest args)
               (let ((env ,env))
                 (apply ,fn args)))))
             
(but more optimized) which makes the environment end up in the
constants vector.

I guess it would be best if closures were implemented the same way,
regardless of whether they are compiled from Emacs Lisp or Common
Lisp.  So whatever Miles Bader's lexical stuff ends up doing, I'd
like to be able to do the same.

So, in summary:
(aref 0-5: as before)
 aref 6: closure environment (or as the first constant)
 aref 7: meta data, as an alist (or plist?)
 aref 8 and above: reserved for emacs?  any slots for wacky users?

I guess a very extensible scheme would be to create a new function
allocate-byte-code-element which returnes an index to a byte code
vector element which can be used for any purpose the caller likes, but
then, is the complexity (though small) worth it?

  (defvar byte-code-vector-index-free 6)  ;; or 7 for Miles B
  (defun allocate-byte-code-element ()
    (prog1 byte-code-vector-index-free
      (setq byte-code-vector-index-free (1+ byte-code-vector-index-free))))

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