From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Should lexical-let use let in the situation lexical-binding is t ? Date: Tue, 18 Sep 2012 08:44:39 -0400 Message-ID: References: <20120918192807.6a426ea58372355516a2ea50@cx4a.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1347972297 27134 80.91.229.3 (18 Sep 2012 12:44:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2012 12:44:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tomohiro Matsuyama Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 18 14:45:01 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TDxAh-0003ps-71 for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2012 14:44:59 +0200 Original-Received: from localhost ([::1]:42156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDxAc-0007Yc-T2 for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2012 08:44:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDxAW-0007Wf-QJ for emacs-devel@gnu.org; Tue, 18 Sep 2012 08:44:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDxAP-0003z2-JL for emacs-devel@gnu.org; Tue, 18 Sep 2012 08:44:48 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:16144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDxAP-0003yv-FF for emacs-devel@gnu.org; Tue, 18 Sep 2012 08:44:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAG6Zu09Ld+qU/2dsb2JhbABEsX2CFIEIghUBAQQBViMFCwsOJhIUGA0kiBwFugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="198589148" Original-Received: from 75-119-234-148.dsl.teksavvy.com (HELO pastel.home) ([75.119.234.148]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Sep 2012 08:44:40 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E404B59041; Tue, 18 Sep 2012 08:44:39 -0400 (EDT) In-Reply-To: <20120918192807.6a426ea58372355516a2ea50@cx4a.org> (Tomohiro Matsuyama's message of "Tue, 18 Sep 2012 19:28:07 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153379 Archived-At: > I'm not sure that is valid, but if so, I think we should modify > lexical-let to improve performance. As mentioned in my reply there, the two aren't quite compatible (because (lexical-let ((tab-width 4)) foo) will be a lexical binding, whereas (let ((tab-width 4)) foo) will be a dynamic binding) so we could do that, but only after checking that the lexical-let-bound variable is not defvar'd, and this requires checking byte-compile-bound-variables, so it's rather ugly to do from a macro. Furthermore, it can be non-trivial for the macro to figure out whether it's really called in a lexical-binding context or not and whether byte-compile-bound-variables is relevant, since the macro call being expanded might come from code being executed during compilation (e.g. loaded via a `require') rather than from code being compiled. I've recently tightened a bit the way lexical-binding is set, so that testing `lexical-binding' in a macro should now be fairly accurate (the C code rebinds lexical-binding during macro-calls to reflect whether the macro is expanded in a lexical-binding context or not, rather than leaving the variable's value determined by the current-buffer's local value), but testing byte-compile-bound-variables is likely to be unreliable. IOW, it's OK for the OP to use such a macro himself because he hopefully won't fall into those traps in those places where he uses it, but if we do right in lexical-let so that it applies to all uses of lexical-let, there's a good chance we could bump into those problems, and they may be very difficult to track down. Stefan