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 13:12:50 -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> <85ekq8dp02.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 1083173898 7305 80.91.224.253 (28 Apr 2004 17:38:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2004 17:38:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 28 19:38:10 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 1BIt0c-0004Qv-00 for ; Wed, 28 Apr 2004 19:38:10 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BIt0c-00011J-00 for ; Wed, 28 Apr 2004 19:38:10 +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 1BIsn5-0003BG-0d for emacs-devel@quimby.gnus.org; Wed, 28 Apr 2004 13:24:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BIsmD-00038c-Rz for emacs-devel@gnu.org; Wed, 28 Apr 2004 13:23:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BIslh-0002yd-A5 for emacs-devel@gnu.org; Wed, 28 Apr 2004 13:23:16 -0400 Original-Received: from [206.47.199.163] (helo=simmts5-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BIsc8-0000j9-57 for emacs-devel@gnu.org; Wed, 28 Apr 2004 13:12:52 -0400 Original-Received: from empanada.local ([67.71.118.150]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040428171250.IDTR12285.simmts5-srv.bellnexxia.net@empanada.local>; Wed, 28 Apr 2004 13:12:50 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id 5730E15DF0B; Wed, 28 Apr 2004 13:12:51 -0400 (EDT) Original-To: Lars Brinkhoff In-Reply-To: <85ekq8dp02.fsf@junk.nocrew.org> Original-Lines: 35 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:22312 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22312 >> 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. Right, but in the constants-vector if the wrapper function used for the closure, whereas I was thinking of removing the indirection and do something more like (defun make-closure (env args bytes csts &rest rest) (apply 'make-byte-code args bytes (vconcat (vector env) csts) rest)) > 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? I think it's way overkill. Stefan