From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp lexical-let Date: Wed, 22 Jul 2009 16:50:49 -0400 Message-ID: References: <4A661B73.4090706@domob.eu> <4A66D7BF.5060606@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248296321 15719 80.91.229.12 (22 Jul 2009 20:58:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jul 2009 20:58:41 +0000 (UTC) Cc: Andy Wingo , guile-devel , Neil Jerram To: Daniel Kraft Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 22 22:58:33 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 1MTitV-0000TL-D9 for guile-devel@m.gmane.org; Wed, 22 Jul 2009 22:58:33 +0200 Original-Received: from localhost ([127.0.0.1]:60004 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTitU-0007RB-7F for guile-devel@m.gmane.org; Wed, 22 Jul 2009 16:58:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTime-0003mj-7O for guile-devel@gnu.org; Wed, 22 Jul 2009 16:51:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTimZ-0003jf-C6 for guile-devel@gnu.org; Wed, 22 Jul 2009 16:51:27 -0400 Original-Received: from [199.232.76.173] (port=37548 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTimZ-0003jO-6C for guile-devel@gnu.org; Wed, 22 Jul 2009 16:51:23 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:52260 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MTimK-0002Nq-K2 for guile-devel@gnu.org; Wed, 22 Jul 2009 16:51:22 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6MKoniq005055; Wed, 22 Jul 2009 16:50:50 -0400 (EDT) In-Reply-To: <4A66D7BF.5060606@domob.eu> X-Mailer: Apple Mail (2.935.3) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:8917 Archived-At: On Jul 22, 2009, at 05:11, Daniel Kraft wrote: > 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. Oh... I may have seriously misunderstood; sorry about that. That's what comes from not having bothered to look. :-) In that case, the cl package is probably the thing to look at for now; it is used by a bunch of other things in Emacs. But I do expect lexbind is going to get merged in eventually, so keeping that in mind for the future would be wise too. > 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. I think you could make an argument for doing it either way. The interesting question would be whether anyone is depending on the behavior from the cl package. Ken