From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lars Brinkhoff Newsgroups: gmane.emacs.devel Subject: Re: User-reserved element in byte code vectors Date: 28 Apr 2004 18:51:57 +0200 Organization: nocrew Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <85ekq8dp02.fsf@junk.nocrew.org> References: <85k7036eqr.fsf@junk.nocrew.org> <85smepfzqo.fsf@junk.nocrew.org> <85ad0wfkms.fsf_-_@junk.nocrew.org> <85oepcdts4.fsf_-_@junk.nocrew.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083171639 1512 80.91.224.253 (28 Apr 2004 17:00:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2004 17:00:39 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 28 19:00:20 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIsQ0-0001a9-00 for ; Wed, 28 Apr 2004 19:00:20 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIsQ0-0000Qc-00 for ; Wed, 28 Apr 2004 19:00:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIsLl-0004Y5-Eo for emacs-devel@quimby.gnus.org; Wed, 28 Apr 2004 12:55:57 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BIsLY-0004WY-UI for emacs-devel@gnu.org; Wed, 28 Apr 2004 12:55:44 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BIsL1-0004PM-T3 for emacs-devel@gnu.org; Wed, 28 Apr 2004 12:55:43 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIsI0-0003or-Mc for emacs-devel@gnu.org; Wed, 28 Apr 2004 12:52:04 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BIsHw-0006zL-00 for ; Wed, 28 Apr 2004 18:52:00 +0200 Original-Received: from junk.nocrew.org ([213.242.147.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Apr 2004 18:52:00 +0200 Original-Received: from lars by junk.nocrew.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Apr 2004 18:52:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 54 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: junk.nocrew.org User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22309 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22309 Stefan Monnier 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/