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: Function vectors: +funvec-20030516-0-c.patch Date: 17 May 2004 12:09:32 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <874qqiao9o.fsf@tc-1-100.kawasaki.gol.ne.jp> <20040515231754.GB20052@fencepost> <87r7tlggue.fsf_-_@tc-1-100.kawasaki.gol.ne.jp> <20040517000346.GA25130@fencepost> <20040517003032.GA31108@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084818008 26795 80.91.224.253 (17 May 2004 18:20:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 18:20:08 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 17 20:19:59 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 1BPmiV-00019L-00 for ; Mon, 17 May 2004 20:19:59 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPmiV-0001TM-00 for ; Mon, 17 May 2004 20:19:59 +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 1BPmaA-0001qx-8X for emacs-devel@quimby.gnus.org; Mon, 17 May 2004 14:11:22 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPkh4-00047h-5r for emacs-devel@gnu.org; Mon, 17 May 2004 12:10:22 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPkgM-0003xR-0g for emacs-devel@gnu.org; Mon, 17 May 2004 12:10:14 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPkgL-0003wz-7j; Mon, 17 May 2004 12:09:37 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 4F02F20D16; Mon, 17 May 2004 12:09:32 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 3E8068CA23; Mon, 17 May 2004 12:09:32 -0400 (EDT) Original-To: Miles Bader In-Reply-To: <20040517003032.GA31108@fencepost> Original-Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) 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:23594 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23594 >> It adds yet-anoter-form-of-function. I.e. it makes function calls yet >> a tiny bit slower, forces placed that look inside functions (like >> describe-function) to deal with yet-another-case, ... > Well, as I said, the cost is `negligible' -- it's essentially another EQ > test, a branch, and some adds, in a non-fast-path location. It shares 99% > of its code with normal curry. Well, "negligible" is always "w.r.t" something, typically the upside. You conveniently ignored `describe-function' and `defadvice'... > Probably the biggest cost is actually the docstring. >> From what I can tell, rcurry will simply never be used. > Er, I just said that I'd used it in the past; don't you believe me? You said in Dylan. Dylan is not Elisp. And if someday somewhere someone uses rcurry, I still don't find this very compeling since an elisp implementation on top of existing functionality would work just as well. > It's good to think about cost/benefit tradeoffs, but there's a point at > which it can become silly. Think about what happens to the byte-code optimizer when it inlines a function: will it treat rcurry specially as well? What about mixed-curry when we add it (which would also be a negligible addition, after all)? Let's only add things we need. For one I don't believe that we even need "curry" as such. What we need is a cheap&fast way to implement closures. "curry" is a way to do that, so it makes sense to add it in the C core. "rcurry" provides no such useful functionality and can thus just as well be implemented in elisp. If we later on see that it indeed should deserve a more efficient treatment, then we can always put it back in C. Stefan