From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: User-reserved element in byte code vectors Date: 18 May 2004 09:17:44 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <85ekpz5twj.fsf@junk.nocrew.org> <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 1084923327 2107 80.91.224.253 (18 May 2004 23:35:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 May 2004 23:35:27 +0000 (UTC) Cc: lars@nocrew.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 19 01:35:17 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 1BQE7A-0004BI-00 for ; Wed, 19 May 2004 01:35:16 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQE7A-0008HD-00 for ; Wed, 19 May 2004 01:35:16 +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 1BQDMG-0001NH-Q2 for emacs-devel@quimby.gnus.org; Tue, 18 May 2004 18:46:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQDHF-0000dP-La for emacs-devel@gnu.org; Tue, 18 May 2004 18:41:37 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQDGK-0000RA-Tg for emacs-devel@gnu.org; Tue, 18 May 2004 18:41:12 -0400 Original-Received: from [206.47.199.141] (helo=simmts12-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQ4Ti-0006bn-8c; Tue, 18 May 2004 09:17:54 -0400 Original-Received: from empanada.local ([67.71.116.83]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040518131747.DGXC15788.simmts12-srv.bellnexxia.net@empanada.local>; Tue, 18 May 2004 09:17:47 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id 9D30019005A; Tue, 18 May 2004 09:17:44 -0400 (EDT) Original-To: Miles Bader In-Reply-To: <20040517220612.GA6421@fencepost> Original-Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:23666 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23666 >> > My idea is that it would say where to fit the new args around the old >> > args. For instance, you might want to curry args 2 and 3. This would >> > be easy if the first slot has a list saying where the curried args go. >> > For instance, a list of integers saying which positions to use >> > the curried args in. >> >> We already have a very simple way to express such things: > I think the case where using `lambda' becomes annoying is when you have a > variable-length arglist, which with lambda would require using &rest or > something, and so do lots of run-time consing. I haven't noticed anybody complain about it until now. It'll work just fine, although a bit slower, but a lot of Elisp code is not speed-sensitive and if you care about speed and don't have rcurry, you can almost always reorganize your code a bit such that your arguments come in the right order. > It's probably true that at this point it's over-engineering, but perhaps > Richard's stance of just leaving a single nil slot available for future > exploration is reasonable. A single vector slot is not very expensive. 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. > On the other hand, I'm not sure it's really better than omitting the slot > now, and later adding a `super-curry' funvec-kind that has the slot -- code > that cares about funvec layout would have to be amended to deal with non-nil > values of the slot anyay, so making it understand `super-curry' isn't much > different, right? If Stefan's intuition proves right, and `super-curry' > never gets added, then it will represent a small savings. There are many ways to provide the proposed behaviors, but since we haven't seen them needed, we have no clue which implementation would be best. 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.... Are you people serious? Stefan