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: Tue, 18 May 2004 19:45:46 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040518234546.GA32327@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 1084930120 14031 80.91.224.253 (19 May 2004 01:28:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 May 2004 01:28:40 +0000 (UTC) Cc: lars@nocrew.org, emacs-devel@gnu.org, rms@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 19 03:28:30 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 1BQFsk-0001rf-00 for ; Wed, 19 May 2004 03:28:30 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQFsk-0002Eu-00 for ; Wed, 19 May 2004 03:28:30 +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 1BQFm7-0004bW-Df for emacs-devel@quimby.gnus.org; Tue, 18 May 2004 21:21:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQFm0-0004aZ-Bf for emacs-devel@gnu.org; Tue, 18 May 2004 21:21:32 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQFlS-0004Po-IS for emacs-devel@gnu.org; Tue, 18 May 2004 21:21:29 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQEHQ-0004GI-Fu for emacs-devel@gnu.org; Tue, 18 May 2004 19:45:52 -0400 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.34) id 1BQEHK-0002L4-7b; Tue, 18 May 2004 19:45:46 -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:23673 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23673 On Tue, May 18, 2004 at 09:17:44AM -0400, Stefan Monnier wrote: > Not even necessary. We can easily do > > (defmacro rcurry (f &rest args) > `(curry rcurry-helper f ,@args)) > > and make a rcurry-helper subroutine. And for Richard's permutation of > args, we can also do it that way with curry-reorg auxiliary function. Hmmm, I think I'm convinced. There is one little wrinkle though -- by the time something like `rcurry-helper' gets called, some information has been lost: which args are from the funvec, and which are user args. So I think you'd have to explicitly include the dividing point, e.g.: (defmacro rcurry (f &rest args) `(curry rcurry-helper (length args) f ,@args)) Still, since presumably such cases will be much rarer than typical curry uses (e.g., closures), I agree that it seems better to pay the small extra cost there, rather than adding it to every curry. Since you've got to include the extra slot anyway, you could make it something more general, e.g., called it `permuted-funcall' instead of `rcurry-helper', and allow wackiness to ensue. :-) In either case, it could be useful for direct use by programmers too, e.g., to cheaply convert from one argument convention to another, you could make a curry-object that omits the arguments, but still specifies the `permutation recipe'. > 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.... Well, OK, I'm now on your side, but it's still Richard's call. Richard, if you don't care very much though, I'll just take out the reserved slot; I agree with Stefan that there's ample room for expansion without it, and that it's better to add a slight extra expense to exceptional cases rather than to every curry object. -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x)))