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: 03 May 2004 08:08:30 +0200 Organization: nocrew Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <853c6i82ld.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> <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 1083564614 21734 80.91.224.253 (3 May 2004 06:10:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 May 2004 06:10:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 03 08:10:07 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 1BKWeV-0006ov-00 for ; Mon, 03 May 2004 08:10:07 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKWeV-0000Rj-00 for ; Mon, 03 May 2004 08:10:07 +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 1BKWdk-00021e-Gm for emacs-devel@quimby.gnus.org; Mon, 03 May 2004 02:09:20 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKWdW-0001yW-TF for emacs-devel@gnu.org; Mon, 03 May 2004 02:09:06 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKWcz-0001PK-7b for emacs-devel@gnu.org; Mon, 03 May 2004 02:09:05 -0400 Original-Received: from [213.242.147.30] (helo=junk.nocrew.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKWcy-0001PD-P9 for emacs-devel@gnu.org; Mon, 03 May 2004 02:08:32 -0400 Original-Received: from lars by junk.nocrew.org with local (Exim 3.35 #1 (Debian)) id 1BKWcw-0006nk-00; Mon, 03 May 2004 08:08:30 +0200 Original-To: Stefan Monnier In-Reply-To: Original-Lines: 48 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:22580 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22580 Stefan Monnier writes: > > > 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. Yes, I agree. > 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. Yes, and maybe some consing of the &rest argument to the wrapper? > 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. Right. For reference, my wrapper function looks like this: #[(&rest args) "<8 bytes>" [env args apply ] 3] > 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". Sorry, I didn't mean to imply that anything sucks. > 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. Not as an environment slot for current Emacs Lisp code, no. > 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. That would be nice. -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/