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: 06 May 2004 12:55:49 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <85smepfzqo.fsf@junk.nocrew.org> <85ad0wfkms.fsf_-_@junk.nocrew.org> <85oepcdts4.fsf_-_@junk.nocrew.org> <85vfjf9s4j.fsf@junk.nocrew.org> <20040502094316.GB2836@fencepost> <85fzaiakb9.fsf@junk.nocrew.org> <20040503195701.GD21891@fencepost> <85ekpz5twj.fsf@junk.nocrew.org> Reply-To: Miles Bader NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083816348 30662 80.91.224.253 (6 May 2004 04:05:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 May 2004 04:05:48 +0000 (UTC) Cc: Lars Brinkhoff , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 06 06:05:39 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 1BLa8h-0004th-00 for ; Thu, 06 May 2004 06:05:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BLa8h-00049O-00 for ; Thu, 06 May 2004 06:05:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BLa3o-00055m-US for emacs-devel@quimby.gnus.org; Thu, 06 May 2004 00:00:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BLa3T-00051p-Dp for emacs-devel@gnu.org; Thu, 06 May 2004 00:00:15 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BLa2w-0004P5-QU for emacs-devel@gnu.org; Thu, 06 May 2004 00:00:13 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1BLa2w-0004Oa-3m; Wed, 05 May 2004 23:59:42 -0400 Original-Received: from [202.32.8.202] (helo=TYO202.gate.nec.co.jp) by mx20.gnu.org with esmtp (Exim 4.30) id 1BLa0s-0001XM-2o; Wed, 05 May 2004 23:57:34 -0400 Original-Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i463tsh20135; Thu, 6 May 2004 12:57:04 +0900 (JST) Original-Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i463trp23313; Thu, 6 May 2004 12:55:53 +0900 (JST) Original-Received: from edsgm01.lsi.nec.co.jp ([10.50.208.11]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i463tqT19087; Thu, 6 May 2004 12:55:52 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edsgm01.lsi.nec.co.jp (8.12.10/8.12.10) with ESMTP id i463tpf3015151; Thu, 6 May 2004 12:55:51 +0900 (JST) Original-Received: from mcspd15 (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id i463toaQ001298; Thu, 6 May 2004 12:55:50 +0900 (JST) Original-Received: by mcspd15 (Postfix, from userid 31295) id 0FD0D48E; Thu, 6 May 2004 12:55:49 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: Original-Lines: 54 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:22830 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22830 Richard Stallman writes: > Instead we could dedicate slot 7 to a vector of curried args. That > would not interfere with other uses of other slots. I'm a bit confused by how Lars is suggesting that byte-code vectors be used for currying. From the Ffuncall code-snipped he posted, I gather that he was saying that the curried args be just a way to attach magic arguments to an existing byte-code vector. However currying is usually used as a way of _wrapping_ an existing function. Morever, it should (1) support interpreted functions as well, and (2) be efficient (no consing when calling a curried function, and ideally, little additional overhead compared to calling a non-curried function). Using his code, one could use byte-code objects with the traditional first 6-slots containing a special `currying trampoline' function, but really I'm not sure the point -- doing that seems to have lots of disadvantages: (1) It would require consing for each call in many cases (2) It would incur extra time overhead when calling the curried function (executing the trampoline function), (3) Constructing curried functions would be a lot more heavyweight, because the various magic byte-code bits have to be constructed (_especially_ if you tried to do analysis to avoid some consing overhead by not using &rest when possible). (4) If you're going to construct special trampoline functions anyway, why not just stick the curried arguments into the byte-code constant vector in the first place? So while I can see that maybe using a non-standard vector type like byte-code vectors could be a good idea, the current suggestions don't seem very good. How about the following: If a byte-code vector's first element is `curry', treat the remaining elements the same way my current (normal vector) currying implementation works, otherwise treat it as a normal byte-code function. Since the first element in a normal byte-code object is an arg-list, it should never be an atom, so there shouldn't be any conflict between the two uses. So for example: (curry '+ 1 2 3) => #[curry + 1 2 3] -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_.