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: 02 May 2004 20:59:18 +0200 Organization: nocrew Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <85pt9m8xkp.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> <85vfjf9s4j.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 1083524577 30419 80.91.224.253 (2 May 2004 19:02:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 May 2004 19:02:57 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 02 21:02:51 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 1BKMEk-0000qn-00 for ; Sun, 02 May 2004 21:02:50 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKMEk-0006bB-00 for ; Sun, 02 May 2004 21:02:50 +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 1BKMDs-0005yX-UR for emacs-devel@quimby.gnus.org; Sun, 02 May 2004 15:01:56 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKMDn-0005x7-C9 for emacs-devel@gnu.org; Sun, 02 May 2004 15:01:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKMDH-0005rQ-GX for emacs-devel@gnu.org; Sun, 02 May 2004 15:01:50 -0400 Original-Received: from [213.242.147.30] (helo=junk.nocrew.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKMBO-0004sD-F4 for emacs-devel@gnu.org; Sun, 02 May 2004 14:59:22 -0400 Original-Received: from lars by junk.nocrew.org with local (Exim 3.35 #1 (Debian)) id 1BKMBK-0007z0-00; Sun, 02 May 2004 20:59:18 +0200 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 28 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:22549 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22549 Stefan Monnier writes: > > > 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 costly, but it makes the function call faster. > > The downside to that is that you would have to create both a new > > byte code object, and a new constants vector every time a closure > > is created. > Yes, as I said above, "it makes closure construction slower and more > costly". But it does make calling a closure faster since closures > are then plain old normal byte-code objects supported natively > whereas in your case you need to do some massaging before doing the > actual `funcall'. No, that's not necessary. As long as the first six element in the byte code object are as Emacs expects them to be, anything can be stuffed into additional elements. At least in GNU Emacs 20.7, 21.3, and CVS. > Furthermore, with your scheme you can't call closures in the same > way as built-in functions. How do you deal with that without > slowing down function calls or closure construction too much? A closure can be a byte code object with an extra element. -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/