unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
To: Daniel Kraft <d@domob.eu>
Cc: Andy Wingo <wingo@pobox.com>, guile-devel <guile-devel@gnu.org>,
	Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: Elisp lexical-let
Date: Wed, 22 Jul 2009 16:50:49 -0400	[thread overview]
Message-ID: <F88A3E64-7F70-48A8-9D28-8D229C3E9056@raeburn.org> (raw)
In-Reply-To: <4A66D7BF.5060606@domob.eu>

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




  parent reply	other threads:[~2009-07-22 20:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21 19:48 Elisp lexical-let Daniel Kraft
2009-07-21 21:46 ` Ken Raeburn
2009-07-22  9:11   ` Daniel Kraft
2009-07-22 13:00     ` Marijn Schouten (hkBst)
2009-07-22 19:24       ` Daniel Kraft
2009-07-23 15:24         ` Marijn Schouten (hkBst)
2009-07-23 16:13           ` Mark H Weaver
2009-07-23 20:53             ` Andy Wingo
2009-07-23 17:05           ` Daniel Kraft
2009-07-24 11:09             ` Marijn Schouten (hkBst)
2009-07-22 20:50     ` Ken Raeburn [this message]
2009-07-23 10:47       ` Daniel Kraft
2009-07-23 20:56         ` Andy Wingo
2009-07-24  6:50           ` Daniel Kraft
2009-07-23 20:49     ` Andy Wingo
2009-07-23 22:39 ` Andy Wingo
2009-07-24  7:08   ` Daniel Kraft
2009-07-24 11:42     ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F88A3E64-7F70-48A8-9D28-8D229C3E9056@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=d@domob.eu \
    --cc=guile-devel@gnu.org \
    --cc=neil@ossau.uklinux.net \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).