-----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-----
