From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: User-reserved element in byte code vectors Date: Thu, 6 May 2004 16:39:05 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040506203905.GA10369@fencepost> References: <85vfjf9s4j.fsf@junk.nocrew.org> <20040502094316.GB2836@fencepost> <85fzaiakb9.fsf@junk.nocrew.org> <20040503195701.GD21891@fencepost> <85ekpz5twj.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 1083878937 11365 80.91.224.253 (6 May 2004 21:28:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 May 2004 21:28:57 +0000 (UTC) Cc: Lars Brinkhoff , emacs-devel@gnu.org, rms@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 06 23:28:33 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 1BLqPw-0004AW-00 for ; Thu, 06 May 2004 23:28:32 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BLqPv-0001h2-00 for ; Thu, 06 May 2004 23:28:31 +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 1BLqLt-0003Va-G8 for emacs-devel@quimby.gnus.org; Thu, 06 May 2004 17:24:21 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BLqKw-0003U6-Fd for emacs-devel@gnu.org; Thu, 06 May 2004 17:23:22 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BLpeB-0003uv-OB for emacs-devel@gnu.org; Thu, 06 May 2004 16:39:42 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BLpeB-0003uX-HB for emacs-devel@gnu.org; Thu, 06 May 2004 16:39:11 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.24) id 1BLpe5-0003wO-56; Thu, 06 May 2004 16:39:05 -0400 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop 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:22882 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22882 On Thu, May 06, 2004 at 10:24:18AM -0400, Stefan Monnier wrote: > > (curry '+ 1 2 3) > > => #[curry + 1 2 3] ... > But of course it will break some elisp code that expects a byte-compiled-p > object to have a particular shape (typically code that wants to get at the > docstring, or the arglist, or the interactive spec). I think such code will be (1) extremely rare, and (2) the sort of very specialized thing that will not be done by externally-maintained user packages. So it should be no problem to look for and fix it ahead of time (and once fixed, such code will kosher for future uses of byte-vectors in this manner, with different first-element tags). > I'm still not sure I understand what it would be used for. > > Is that how you construct closures in your lexbind branch? Yes (well, of course there I currently still use normal vectors, but I'll obviously change to this new representation if it can go into the trunk). > I thought you used extra arguments in byte-compiled-objects for that. No; the extra arg in byte-compiled-objects is a flag telling eval to use lexical binding for the arguments -- it's a static part of the byte-code-object, and only applies to byte-code-objects, so it makes sense to put it there. [Remember closures are created dynamically, so all the extra futzing around required to use an `extra argument in byte-compiled-objects' would be pretty annoying. See my earlier reply to Lars for a list of reasons...] -Miles -- .Numeric stability is probably not all that important when you're guessing.