From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp lexical-let Date: Wed, 22 Jul 2009 11:11:27 +0200 Message-ID: <4A66D7BF.5060606@domob.eu> References: <4A661B73.4090706@domob.eu> 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 1248255142 8554 80.91.229.12 (22 Jul 2009 09:32:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 09:32:22 +0000 (UTC) Cc: guile-devel To: Ken Raeburn , Andy Wingo , Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 22 11:32:15 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MTY9X-0005Tm-8d for guile-devel@m.gmane.org; Wed, 22 Jul 2009 11:30:23 +0200 Original-Received: from localhost ([127.0.0.1]:38201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTY9W-0008Pj-IA for guile-devel@m.gmane.org; Wed, 22 Jul 2009 05:30:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTXqv-0001d8-Oc for guile-devel@gnu.org; Wed, 22 Jul 2009 05:11:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTXqs-0001cE-0L for guile-devel@gnu.org; Wed, 22 Jul 2009 05:11:09 -0400 Original-Received: from [199.232.76.173] (port=39296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTXqr-0001c1-Gm for guile-devel@gnu.org; Wed, 22 Jul 2009 05:11:05 -0400 Original-Received: from tatiana.utanet.at ([213.90.36.46]:55604) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTXqq-0005Yc-UP for guile-devel@gnu.org; Wed, 22 Jul 2009 05:11:05 -0400 Original-Received: from paris.xoc.tele2net.at ([213.90.36.7]) by tatiana.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MTXql-0008Ro-Lh; Wed, 22 Jul 2009 11:10:59 +0200 Original-Received: from d86-33-51-101.cust.tele2.at ([86.33.51.101] helo=[192.168.1.18]) by paris.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MTXql-0006lr-H2; Wed, 22 Jul 2009 11:10:59 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8911 Archived-At: Ken Raeburn wrote: > On Jul 21, 2009, at 15:48, Daniel Kraft wrote: >> Especially, the question is about "what happens" when a lexical >> variable is inside its scope again bound dynamically (say via let or a >> lambda expression). > > Oh, don't stop there... let's get some buffer-local or frame-local > bindings into the mix too! :-) > There are probably corner cases where the only "specification" you're > likely to find is "what Emacs does when you try it". And, if the goal > is to support the existing body of Lisp code (e.g., if Emacs 24 goes out > with lexical binding support, and people start using it), there's a > tradeoff between what seems logical or convenient to you, and what > behavior of Emacs the existing code is going to expect. Maybe not in > weird corner cases, but cases like you describe above seem likely, and I > think you'd want to mimic whatever behavior Emacs is going to do. It seemed really hard to me to find at least *basic* information about how the lexbind things works; I did build now an emacs with lexbind from trunk, but so far as I see this is not meant to implement "lexical-let" as the cl package does, but rather allows switching all bindings from dynamic to lexical within one source file. While this is certainly something we could do, too (best via compiler options, I guess?), it is not what I had in mind as the "extension" -- this being implementing the lexical-let as additional construct that establishes lexical binding for certain variables just temporarily. And checks with the cl package's implementation of lexical-let give the result, that an inner let does the same as if it was another lexical-let; that is, does not revert to dynamic binding but rather sets only the lexical value. So, what are the opinions regarding lexical-let as an extension construct? Regarding the behaviour, to me the one described above seems to be a consequence of the implementing with unwind-protect and not necessarily expected -- thus I suggest to implement the version I had in mind, namely that an inner let or argument binding inside a lambda reverts to dynamic binding for that inner scope. This seems more consistent and reasonable to me. Yours, Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri