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: 02 May 2004 17:07:07 -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> <85vfjf9s4j.fsf@junk.nocrew.org> <85pt9m8xkp.fsf@junk.nocrew.org> <85llka8w91.fsf@junk.nocrew.org> <85d65m8tgl.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 1083532221 13585 80.91.224.253 (2 May 2004 21:10:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 May 2004 21:10:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 02 23:10:13 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 1BKOE1-0006yB-00 for ; Sun, 02 May 2004 23:10:13 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKOE1-0000Dx-00 for ; Sun, 02 May 2004 23:10:13 +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 1BKOCJ-0006Rj-Fv for emacs-devel@quimby.gnus.org; Sun, 02 May 2004 17:08:27 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKOBh-0006NK-Tc for emacs-devel@gnu.org; Sun, 02 May 2004 17:07:49 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKOB8-00064w-98 for emacs-devel@gnu.org; Sun, 02 May 2004 17:07:46 -0400 Original-Received: from [206.47.199.164] (helo=simmts6-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKOB3-00063u-DZ for emacs-devel@gnu.org; Sun, 02 May 2004 17:07:09 -0400 Original-Received: from empanada.local ([67.71.116.192]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040502210705.ZJGX8424.simmts6-srv.bellnexxia.net@empanada.local>; Sun, 2 May 2004 17:07:05 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id BFA31173A88; Sun, 2 May 2004 17:07:07 -0400 (EDT) Original-To: Lars Brinkhoff In-Reply-To: <85d65m8tgl.fsf@junk.nocrew.org> Original-Lines: 44 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:22565 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22565 >> I thought you already had it implemented. > I'm using another way which I sketched in a message a few days ago. OK, so I understood it right. My argument is that my way is better than your current way. In your current way (at least what I can tell from your sketch), calling a closure involves really two function calls (you first call the wrapper which then calls the bytecode with the extra environment argument, which is the massaging I was talking about). Constructing a closure in your scheme involves creating the wrapper which boils down to constructing one new byte-compiled-object as well as one new "constants" vector which holds the static environment, the real byte-compiled code and maybe one or two more constants. I.e. one byte-compiled-object and one vector. I.e. the downside of my approach (constructing one byte-compiled-object plus one constants vector) doesn't seem nearly as bad when seen in this light. Admittedly my constants vector will generally be larger so your closure-construction is still usually more efficient, but only profiling can tell if the difference is significant. >> Well, there are two questions: >> - how best to implement closures, given the current Emacs C code. >> - how best to implement closures, assuming we get to change the C code. >> I'm talking about the first question. Miles's work is within the context >> of the second. > I'm interested in both. I'm also interested in both, but we can't say "answer 1 to question 1 sucks because answer 2 to question 2 is better". To get back to the original question, I now don't see how you can usefully put the static environment in slot 7 without making changes to the C code, so there's no point deciding it's reserved for use by elisp packages. As for the rest of the meta-data you might want to put in byte-compiled-objects, maybe we should dedicate one of the slots (maybe the 7th or 8th) for an alist where people can put whatever they want. Stefan