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: 21 May 2004 10:28:43 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <874qqiao9o.fsf@tc-1-100.kawasaki.gol.ne.jp> <20040515231012.GA20052@fencepost> <20040517220612.GA6421@fencepost> <20040519142851.GA17602@fencepost> <20040520003129.GA9853@fencepost> Reply-To: Miles Bader NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085103149 32257 80.91.224.253 (21 May 2004 01:32:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 May 2004 01:32:29 +0000 (UTC) Cc: lars@nocrew.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 21 03:32:20 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 1BQytY-0007gN-00 for ; Fri, 21 May 2004 03:32:20 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQytY-0007Mt-00 for ; Fri, 21 May 2004 03:32:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQysz-0006xC-S2 for emacs-devel@quimby.gnus.org; Thu, 20 May 2004 21:31:45 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQyrl-0006py-OC for emacs-devel@gnu.org; Thu, 20 May 2004 21:30:29 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQyrD-0006S5-91 for emacs-devel@gnu.org; Thu, 20 May 2004 21:30:27 -0400 Original-Received: from [202.32.8.214] (helo=TYO201.gate.nec.co.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQyr7-0006Q8-AK; Thu, 20 May 2004 21:29:54 -0400 Original-Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i4L1T8p17173; Fri, 21 May 2004 10:29:08 +0900 (JST) Original-Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i4L1T8320119; Fri, 21 May 2004 10:29:08 +0900 (JST) Original-Received: from edsgm01.lsi.nec.co.jp ([10.50.208.11]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id i4L1Sn305298; Fri, 21 May 2004 10:29:06 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edsgm01.lsi.nec.co.jp (8.12.10/8.12.10) with ESMTP id i4L1SlXk026966; Fri, 21 May 2004 10:28:47 +0900 (JST) Original-Received: from mctpc71 (mctpc71.ucom.lsi.nec.co.jp [10.30.118.121]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id i4L1SjaQ001378; Fri, 21 May 2004 10:28:45 +0900 (JST) Original-Received: by mctpc71 (Postfix, from userid 31295) id 77A6D435; Fri, 21 May 2004 10:28:43 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: Original-Lines: 37 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:23806 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23806 Richard Stallman writes: > Essentially: > > (let ((env (vector 0))) > (curry env (lambda (env) (aset env 0 (+ (aref env 0) 1))))) > > [of course, `env' is not visible to the user code] > > The word "essentially" means that this isn't really > the answer to the question. What precisely are the Lisp > objects produced? The above code should be exact, except that `env' never exists a normal named variable -- in the compiler it's a variable with a funny (not a symbol) name, and at runtime, it's just a stack location (like other "local" variables). > Why use `curry' for this at all, rather than implementing > a `closure' funcvec type? Well, I have nothing particularly against a special closure type; it's just that in this case it's not necessary -- curry provides exactly the functionality I need. I suppose I could make a special `closure' funvec type that actually shared all its code with that for `curry', if secondary effects are an issue (e.g., what describe-function says, etc). Currently my compiler doesn't even compile such things properly, so things are kind of off my radar... :-/ -Miles -- ===== (^o^; (())) *This is the cute octopus virus, please copy it into your sig so it can spread.