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: pathological byte-compilation Date: 25 Jun 2002 10:51:33 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200206250126.g5P1QY005606@rum.cs.yale.edu> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1024970043 23657 127.0.0.1 (25 Jun 2002 01:54:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2002 01:54:03 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17MfWt-00069S-00 for ; Tue, 25 Jun 2002 03:54:03 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17MfYJ-0003AT-00 for ; Tue, 25 Jun 2002 03:55:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17MfX1-0001G6-00; Mon, 24 Jun 2002 21:54:11 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17MfUk-0001BU-00; Mon, 24 Jun 2002 21:51:50 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5P1pbR10822; Tue, 25 Jun 2002 10:51:37 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5P1pal20324; Tue, 25 Jun 2002 10:51:36 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g5P1pYh05512; Tue, 25 Jun 2002 10:51:34 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g5P1pXK06734; Tue, 25 Jun 2002 10:51:33 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id C6BFE37C8; Tue, 25 Jun 2002 10:51:33 +0900 (JST) Original-To: "Stefan Monnier" System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200206250126.g5P1QY005606@rum.cs.yale.edu> Original-Lines: 26 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5181 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5181 "Stefan Monnier" writes: > (defsubst values (&rest values) > (apply 'list values)) > > in other words, the same result as if we had compiled > (defun foo () (let ((values (list 1))) (apply 'list values))) Of course, part of the problem is that defsubst is rather pathetic, in that it retains the argument bindings no matter what. A very long time ago I wrote an elisp function that analyzes `let' forms and rewrites them to eliminate as many bindings as possible (e.g., when it can substitute a variable's initialization value in the places where the variable is used, without changing any side-effects). That transformation assumed a `lexical style' use of `let', which isn't something you can do generally, but in the case of defsubst, I think it would probably be safe to say that argument bindings are not guaranteed to be visible (via dynamic binding) in functions called from defsubt body. Such an optimization might greatly improve the results of using defsubst... -Miles -- .Numeric stability is probably not all that important when you're guessing.