From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: User-reserved element in byte code vectors Date: Mon, 17 May 2004 07:04:19 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <85fzaiakb9.fsf@junk.nocrew.org> <20040503195701.GD21891@fencepost> <85ekpz5twj.fsf@junk.nocrew.org> <874qqiao9o.fsf@tc-1-100.kawasaki.gol.ne.jp> <20040515231012.GA20052@fencepost> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1084793840 26428 80.91.224.253 (17 May 2004 11:37:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 11:37:20 +0000 (UTC) Cc: lars@nocrew.org, emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 17 13:37:12 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 1BPgQi-0002sm-00 for ; Mon, 17 May 2004 13:37:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPgQi-0008PV-00 for ; Mon, 17 May 2004 13:37:12 +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 1BPfx7-00005p-Ru for emacs-devel@quimby.gnus.org; Mon, 17 May 2004 07:06:38 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPfwy-00005A-FE for emacs-devel@gnu.org; Mon, 17 May 2004 07:06:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPfwR-0008Rt-Jp for emacs-devel@gnu.org; Mon, 17 May 2004 07:06:26 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPfuu-0008Is-4L for emacs-devel@gnu.org; Mon, 17 May 2004 07:04:20 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BPfut-0005pR-Lt; Mon, 17 May 2004 07:04:19 -0400 Original-To: Miles Bader In-reply-to: <20040515231012.GA20052@fencepost> (message from Miles Bader on Sat, 15 May 2004 19:10:12 -0400) 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:23575 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23575 > I recommend leaving the first slot after `curry' unused. That way it > could be used later to control extensions, such as a feature to > specify the order of curried and noncurried arguments. I don't think that's really necessary. My plan for reverse-currying was to simply use another tag, e.g. `rcurry', and that solution serves for other extensions too. Unless someone has a pretty good idea of _what_ such an extra field would be used for, it seems like just wasted space to add it now. 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. Yes, we could use another tag to say that this feature is in use. I think it is cleaner to consider it a part of the currying feature. But I don't say let's implement it now, just leave the slot open.