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: Function vectors: +funvec-20030516-0-c.patch Date: Mon, 17 May 2004 18:21:51 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040517222151.GB6421@fencepost> References: <874qqiao9o.fsf@tc-1-100.kawasaki.gol.ne.jp> <20040515231754.GB20052@fencepost> <87r7tlggue.fsf_-_@tc-1-100.kawasaki.gol.ne.jp> <20040517000346.GA25130@fencepost> <20040517003032.GA31108@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084832872 26461 80.91.224.253 (17 May 2004 22:27:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 22:27:52 +0000 (UTC) Cc: emacs-devel@gnu.org, Richard Stallman , Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 18 00:27:45 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 1BPqaH-0003Yn-00 for ; Tue, 18 May 2004 00:27:45 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPqaG-0007H9-00 for ; Tue, 18 May 2004 00:27:44 +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 1BPqW2-0008C4-8j for emacs-devel@quimby.gnus.org; Mon, 17 May 2004 18:23:22 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPqVC-0008Bm-CR for emacs-devel@gnu.org; Mon, 17 May 2004 18:22:30 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPqUg-00085Q-B8 for emacs-devel@gnu.org; Mon, 17 May 2004 18:22:29 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPqUg-00085M-3b for emacs-devel@gnu.org; Mon, 17 May 2004 18:21:58 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.34) id 1BPqUZ-00057w-OH; Mon, 17 May 2004 18:21:51 -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:23598 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23598 On Mon, May 17, 2004 at 12:09:32PM -0400, Stefan Monnier wrote: > Let's only add things we need. For one I don't believe that we even need > "curry" as such. What we need is a cheap&fast way to implement closures. > "curry" is a way to do that, so it makes sense to add it in the C core. > "rcurry" provides no such useful functionality and can thus just as well be > implemented in elisp. If we later on see that it indeed should deserve > a more efficient treatment, then we can always put it back in C. Fair enough; nobody likes rcurry, so I'll take it out. BTW, this brings back a question you asked in private email a loooong time ago (which I never answered): why are the two different representations for compiled and interpreted closures in my lexical-binding implementation. My (unsent) answer then was because the lexical binding implementations for the interpreter is `weird', so needs special treatment to implement closures -- the interpreter depends on funcall &c `resetting' the interpreter's lexical-binding stack at appropriate times to avoid bindings being visible in called functions. My old implementation adds special code to Feval, Ffuncall, etc., to do this, and when it sees a `closure' special form (instead instead of a `lambda'), explicitly uses the intepreted closure's environment instead of setting the interpreter lexical-binding stack to nil. Working on this closure stuff, I now realize I can get rid of the special code and instead use a #[] closure that calls a special `call-interpreted-closure' internal function which just passes its args to the guts of funcall, bypassing the normal `resetting' mechanism. Essentially the same thing, but it gets rid of special-case code in central places like Ffuncall &c. -Miles -- "1971 pickup truck; will trade for guns"