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: Wed, 19 May 2004 10:28:51 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040519142851.GA17602@fencepost> References: <874qqiao9o.fsf@tc-1-100.kawasaki.gol.ne.jp> <20040515231012.GA20052@fencepost> <20040517220612.GA6421@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084977294 20829 80.91.224.253 (19 May 2004 14:34:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 May 2004 14:34:54 +0000 (UTC) Cc: lars@nocrew.org, emacs-devel@gnu.org, Stefan Monnier , miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 19 16:34:37 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 1BQS9V-00039n-00 for ; Wed, 19 May 2004 16:34:37 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQS9U-0000SG-01 for ; Wed, 19 May 2004 16:34:36 +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 1BQS4n-0003Yh-Ci for emacs-devel@quimby.gnus.org; Wed, 19 May 2004 10:29:45 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQS4Z-0003Wi-E6 for emacs-devel@gnu.org; Wed, 19 May 2004 10:29:31 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQS42-0003Ol-K9 for emacs-devel@gnu.org; Wed, 19 May 2004 10:29:29 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQS42-0003Oe-9Y for emacs-devel@gnu.org; Wed, 19 May 2004 10:28:58 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.34) id 1BQS3v-0006vk-O6; Wed, 19 May 2004 10:28:51 -0400 Original-To: Richard Stallman 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:23709 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23709 On Wed, May 19, 2004 at 09:45:43AM -0400, Richard Stallman wrote: > I think paying one extra word for each and every closure ever created > from now on, just because of the remote possibility that someone will > want something like rcurry and will want it to be really efficient and > that someone will not prefer some other implementation.... > > We're talking about currying--what does that have to do with > closures? There is some similarity between the two, but I don't > think we want to use `curry' to implement closures. > It seems to me that if we add any facility for closures > we might as well make it a primitive that does precisely closures. For what sort of closures? This currying implementation originated with the closures in my lexical-binding implementation -- _after_ I had implemented the mechanism for doing closures, I realized that it was precisely the same as the currying operator, and so now I called it that, as that's a more interesting operation in standard emacs. But it's the same thing as closures for me (not just similar, the same). Do you some sort of closure implementation in mind that's necessarily different? -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein