From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: "simplifications" Date: Mon, 19 Nov 2007 22:59:14 -0500 Message-ID: References: <86ejem1pig.fsf@lola.quinscape.zz> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1195531234 31548 80.91.229.12 (20 Nov 2007 04:00:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2007 04:00:34 +0000 (UTC) Cc: lekktu@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 20 05:00:39 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IuKHu-0001v0-FO for ged-emacs-devel@m.gmane.org; Tue, 20 Nov 2007 05:00:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IuKHg-0001nD-UE for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2007 23:00:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IuKGc-0001CZ-3B for emacs-devel@gnu.org; Mon, 19 Nov 2007 22:59:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IuKGZ-00019z-Vk for emacs-devel@gnu.org; Mon, 19 Nov 2007 22:59:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IuKGZ-00019c-Pw for emacs-devel@gnu.org; Mon, 19 Nov 2007 22:59:15 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IuKGZ-0007MK-EX for emacs-devel@gnu.org; Mon, 19 Nov 2007 22:59:15 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IuKGY-0008Pr-SO; Mon, 19 Nov 2007 22:59:14 -0500 In-reply-to: (message from Stefan Monnier on Mon, 19 Nov 2007 10:44:27 -0500) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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: news.gmane.org gmane.emacs.devel:83699 Archived-At: >> it doesn't account for the case where >> you do >> (defsubst cadr (debug-on-error) (car (cdr debug-on-error))) >> in which case the optimization is not semantics preserving" I think it is fine to treat the args of a defsubst function in a special way, as long as we document that. However, it would be easy enough to turn off the optimization for variables that are defvar'd. Well, my optimization is not specific to defsubst, so it will also remove the let-binding in: (let ((debug-on-error t)) (car (car (cdr x)))) Which optimization is that one? It too needs something to prevent it from removing that binding, such as don't remove bindings for variables that have been defvar'd. The optimization I suggested would apply to the expansion of defsubst calls. So it would not apply to `let' expressions that originate in other ways.