From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.emacs.help Subject: Re: lexical-let detail semantics Date: Mon, 27 Jul 2009 16:44:02 +0200 Message-ID: <4A6DBD32.9060100@domob.eu> References: <7c63deuuyr.fsf@pbourguignon.anevia.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248739124 17944 80.91.229.12 (27 Jul 2009 23:58:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 23:58:44 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 28 01:58:38 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVa5U-0000Es-W1 for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Jul 2009 01:58:37 +0200 Original-Received: from localhost ([127.0.0.1]:34546 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVa5U-0000Mr-Fw for geh-help-gnu-emacs@m.gmane.org; Mon, 27 Jul 2009 19:58:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVRQS-0001Cz-VW for help-gnu-emacs@gnu.org; Mon, 27 Jul 2009 10:43:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVRQO-0001B7-Sh for help-gnu-emacs@gnu.org; Mon, 27 Jul 2009 10:43:40 -0400 Original-Received: from [199.232.76.173] (port=48199 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVRQO-0001B3-Nj for help-gnu-emacs@gnu.org; Mon, 27 Jul 2009 10:43:36 -0400 Original-Received: from tatiana.utanet.at ([213.90.36.46]:47745) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MVRQN-00069q-Pm for help-gnu-emacs@gnu.org; Mon, 27 Jul 2009 10:43:36 -0400 Original-Received: from patricia.xoc.tele2net.at ([213.90.36.9]) by tatiana.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MVRQL-0007py-8B for help-gnu-emacs@gnu.org; Mon, 27 Jul 2009 16:43:33 +0200 Original-Received: from d86-33-197-36.cust.tele2.at ([86.33.197.36] helo=[192.168.1.18]) by patricia.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MVRQK-000350-B6 for help-gnu-emacs@gnu.org; Mon, 27 Jul 2009 16:43:33 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: <7c63deuuyr.fsf@pbourguignon.anevia.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-Mailman-Approved-At: Mon, 27 Jul 2009 19:57:16 -0400 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:66438 Archived-At: Hi Pascal, thanks for your nice answers! Pascal J. Bourguignon wrote: > You can avoid the problem by putting the dynaminc bindings outside of > reach of lexical-let: > > (defun call-dyna () > (let ((a 3)) (print (dyna)))) > > (lexical-let ((a 2)) > (call-dyna)) > prints: 3 > --> 3 > > > Notice also that in languages that have both special variables and > lexical variables, it is found worthwhile to keep them in separate > name spaces. In ISO-LISP, this is done with the (dynamic var) form > for special variables. In Common Lisp it's done with the *earmuff* > convention. That's true of course (and good advice), but unfortunatly I'm working on another implementation of elisp which should include lexical-let natively (instead of being a user) and thus I'm forced to care about such special cases, too. > You may report the bug to the maintainers, but I'm not sure it's > worthwhile. If you want a real language, perhaps you could use > emacs-cl? http://www.lisp.se/emacs-cl/ Hm... My main point was whether this is expected behaviour I should mimic in my implementation, but I take your response that you would prefer to have my implementation behave differently (like what I described as my expectation)? Do you think this would lead to compatibility problems with existing code? >> 2) Closures: >> >> I'm happy that lexical-let works well to build closures (and in fact >> it seems that this is the main intention for lexical-let at all); >> however this code does not work as expected: >> >> (setq a 1) >> (lexical-let ((a 2)) >> ((lambda () (print a)))) >> => 1 >> >> I don't know why, but it seems that calling a closure directly fails, >> while storing it and calling it later succeeds (as in the examples at >> http://www.delorie.com/gnu/docs/emacs/cl_21.html for instance). Is >> this a bug or again something expected? If the latter, what's the >> exact rationale and semantics then? > > I guess you have a bug in your version. Mine works ok. > Again, the macroexpansion explains what lexical-let does in this case: Yes, that's right; I checked with a current development version of emacs and there it works as expected. Yours, Daniel