From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: User-reserved element in byte code vectors Date: 28 Apr 2004 11:38:20 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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 1083167649 16114 80.91.224.253 (28 Apr 2004 15:54:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2004 15:54:09 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 28 17:54:01 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 1BIrCl-00033J-00 for ; Wed, 28 Apr 2004 17:42:35 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIrCl-0007UR-00 for ; Wed, 28 Apr 2004 17:42:35 +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 1BIr9r-0003lx-0o for emacs-devel@quimby.gnus.org; Wed, 28 Apr 2004 11:39:35 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BIr9D-0003kt-MR for emacs-devel@gnu.org; Wed, 28 Apr 2004 11:38:55 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BIr8g-0003aX-9F for emacs-devel@gnu.org; Wed, 28 Apr 2004 11:38:53 -0400 Original-Received: from [206.47.199.166] (helo=simmts8-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIr8f-0003aE-Qz for emacs-devel@gnu.org; Wed, 28 Apr 2004 11:38:21 -0400 Original-Received: from empanada.local ([67.71.118.150]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040428153820.NLBT21833.simmts8-srv.bellnexxia.net@empanada.local>; Wed, 28 Apr 2004 11:38:20 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id 1BDB415DEE1; Wed, 28 Apr 2004 11:38:21 -0400 (EDT) Original-To: Lars Brinkhoff In-Reply-To: <85oepcdts4.fsf_-_@junk.nocrew.org> Original-Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:22306 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22306 > It can be useful when compiling languages other than Emacs Lisp to > byte code. In my case, I'm writing a Common Lisp compiler, and it > would be nice to store in the byte code vector things like a closure > environment, a function name, the original lambda expression, and > other meta data that Common Lisp can associate with a function object. I'm beginning to better understand, thank you. >>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? Stefan PS: 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).