From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Zack Weinberg Newsgroups: gmane.emacs.devel Subject: Re: byte-opt.el addition - optimize list of compile-time constants Date: Wed, 08 Dec 2004 21:33:43 -0800 Message-ID: <878y88ox1k.fsf@codesourcery.com> References: <87u0qxgn65.fsf@codesourcery.com> <87llc8tnjr.fsf@codesourcery.com> <878y88s6po.fsf-monnier+emacs@gnu.org> <874qiwqncp.fsf@codesourcery.com> <87llc8qlcb.fsf-monnier+emacs@gnu.org> <87zn0op5dj.fsf@codesourcery.com> <87vfbcp3r2.fsf@codesourcery.com> <87r7m0p1w7.fsf@codesourcery.com> <87mzwoozgf.fsf@codesourcery.com> <874qiwqdo5.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1102570472 10258 80.91.229.6 (9 Dec 2004 05:34:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2004 05:34:32 +0000 (UTC) Cc: snogglethorpe@gmail.com, emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 09 06:34:25 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CcGwb-0003Ui-00 for ; Thu, 09 Dec 2004 06:34:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CcH6T-0008FL-Ta for ged-emacs-devel@m.gmane.org; Thu, 09 Dec 2004 00:44:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CcH69-0008EZ-4B for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:44:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CcH68-0008Dz-JC for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:44:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CcH68-0008Dr-EQ for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:44:16 -0500 Original-Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CcGvx-00015Q-8u for emacs-devel@gnu.org; Thu, 09 Dec 2004 00:33:45 -0500 Original-Received: (qmail 18636 invoked from network); 9 Dec 2004 05:33:44 -0000 Original-Received: from localhost (HELO taltos.codesourcery.com) (zack@127.0.0.1) by mail.codesourcery.com with SMTP; 9 Dec 2004 05:33:44 -0000 Original-Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Wed, 8 Dec 2004 21:33:43 -0800 Original-To: Stefan Monnier In-Reply-To: <874qiwqdo5.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 08 Dec 2004 23:52:50 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30925 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30925 Stefan Monnier writes: > Note that the expression > > (list 1 2 (function (lambda () (with-current-buffer)))) > > can be rejected by the compiler (not enough arguments to the > with-current-buffer macro) whereas > > '(1 2 (function (lambda () (with-current-buffer)))) > > can't because it's just a quoted constant which just happens to look like > invalid code. I'd say that the compiler can and should reject your second example precisely so that the equivalence of the two forms can be preserved. Miles Bader writes: >> Also, in Common Lisp the situation is clearly that the compiler _is_ >> entitled to compile (function ...) wherever it finds it > > Can you provide a reference for this? Given that it's quite > dangerous, I'm skeptical of this claim. I was going by CLTL/1, which says "The value of function is *always* the functional interpretation of [its argument]" (emphasis mine). That's a little ambiguous (although, as standardese goes, pretty damn clear (my brain may have been warped by the C standard's heinous ambiguities)). The most recent edition of the ANSI Common Lisp spec that I can find online [http://www.lispworks.com/reference/HyperSpec/Front/Contents.htm] says basically the same thing, but goes on to observe that function objects may not appear in quoted literals which are to be processed by compile-file. I'm not really sure what the implications are. See . > Note that a possibly safer alternative would be to have the #' > reader macro expand into something less ambiguous during compilation > (e.g., a special non-interned symbol), which the byte-compiler could > then safely interpret inside of constants. This may cause grief for > somebody that uses #' in a non-traditional way, and _expects_ to see > (function (lambda ...)), but that may be an acceptable price. I don't think this is any better than saying that function always means function, even if not evalled. zw