Re: Elisp lexical-let

["Marijn Schouten (hkBst)" <hkBst@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Kraft wrote:
> 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
> 

Guile also has lexical and dynamic variables; the fluids[1]. Queinnec in his
book LiSP also describes a system that has (default) lexical and dynamic
variable, on page 44. In both cases to find the value of a non-default variable
a function is used. Translated to elisp where the situation is dynamic by
default you probably want something like `(lexical x)' to dereference the
lexical variable `x' and also lexical-set(q).

It seems to me that only the dereferencing of variables is dynamic or lexical,
not the binding. Thus you don't even need lexical-let and `(lexical x)' would be
`x' found in the lexical environment (if it isn't found you can generate an
error) and `x' would be searched for in the dynamic environment. Does that make
sense?

[1]:http://www.gnu.org/software/guile/manual/guile.html#Fluids-and-Dynamic-States

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpnDXgACgkQp/VmCx0OL2zpcgCgg2QtK7kL5YJCeVP6hpG87h0f
DCMAn3rgkDIk2GYBqnHJ/JRzjsW7ehBw
=e0Hz
-----END PGP SIGNATURE-----