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: byte-opt.el addition - optimize list of compile-time constants Date: Wed, 08 Dec 2004 21:11:50 -0500 Message-ID: <87llc8qlcb.fsf-monnier+emacs@gnu.org> References: <87u0qxgn65.fsf@codesourcery.com> <878y88hazn.fsf@codesourcery.com> <87llc8tnjr.fsf@codesourcery.com> <878y88s6po.fsf-monnier+emacs@gnu.org> <874qiwqncp.fsf@codesourcery.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1102558351 20119 80.91.229.6 (9 Dec 2004 02:12:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Dec 2004 02:12:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 09 03:12:26 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 1CcDn7-0001gR-00 for ; Thu, 09 Dec 2004 03:12:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CcDx0-0005dQ-4C for ged-emacs-devel@m.gmane.org; Wed, 08 Dec 2004 21:22:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CcDwq-0005cT-EW for emacs-devel@gnu.org; Wed, 08 Dec 2004 21:22:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CcDwp-0005cA-Pe for emacs-devel@gnu.org; Wed, 08 Dec 2004 21:22:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CcDwp-0005c5-MJ for emacs-devel@gnu.org; Wed, 08 Dec 2004 21:22:27 -0500 Original-Received: from [209.226.175.184] (helo=tomts22-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CcDmc-0006lv-4A for emacs-devel@gnu.org; Wed, 08 Dec 2004 21:11:54 -0500 Original-Received: from alfajor ([67.71.27.115]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041209021153.GPNL1919.tomts22-srv.bellnexxia.net@alfajor>; Wed, 8 Dec 2004 21:11:53 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id C2DAAD7318; Wed, 8 Dec 2004 21:11:50 -0500 (EST) Original-To: Zack Weinberg In-Reply-To: <874qiwqncp.fsf@codesourcery.com> (Zack Weinberg's message of "Wed, 08 Dec 2004 17:20:06 -0800") 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:30903 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30903 >>> problem I mentioned earlier - at the point at which the >>> 'byte-optimizer function for list is called, the inner function has >>> not yet been compiled, contrary to the general principle that the >>> byte optimizer operates depth-first. >> >> The "byte-optimizer" has two phases: one done before >> byte-compilation and one after. The byte-optimize-pure-func is done >> before. > Right. I was referring to the source optimizer. Whatever the > consequence, this means the best the source optimizer can do is > convert my `(...) form to a '(...) form, and the inner lambda won't > get compiled. No. If you change byte-compile-constp to recognize `function', together with marking the list/cons/append primitives as pure, it should work. > I suppose I'm trying to fix the bug in the wrong place. I don't think so. At least if you want to solve it in the byte-compiler, doing it at the source-level is probably not a bad idea. > Really, what I want is for the byte compiler to look inside complicated > '(...) forms for embedded lambda expressions, and compile them. I think > it's byte-compile-quote that would be responsible for doing that? That's dangerous because there can be a (lambda ...) form without it actually being meant to be byte-compiled. >> As for your particular problem, there's an easier solution: >> >> (defun foo-aux nil (when (eq (following-char) ?\n) (forward-char 1)) >> ... >> (lambda nil >> '(:a 1 :b 2 :c foo-aux)) > This is what I've done for the time being, but I consider it somewhat > infelicitous, which is why i'm flailing around trying to improve the > byte compiler. What's infelicitous about it? Stefan