guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Elisp lexical-let


From: Marijn Schouten (hkBst)
Subject: Re: Elisp lexical-let
Date: Thu, 23 Jul 2009 17:24:30 +0200
User-agent: Thunderbird 2.0.0.22 (X11/20090630)

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

Daniel Kraft wrote:
> Hi Marijn,
> 
> Marijn Schouten (hkBst) wrote:
>> 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?
> 
> not only the dereferencing, but also the setting must be of a dynamic or
> lexical value;

yes and one could argue that to set a variable you need to dereference it first
too or you won't know which location you're set'ting.

> and at least in my Lisp code, setting is mostly done with
> let's, so at the same time as the "binding".

Unless elisp is the exception, let does not set any variables, but only
introduces bindings.

> So what you propose would then be to have a (lexical sym) for
> referencing and (lexical-set! sym value) for setting in lexical scope --

yes.

> and then as a consequence also a lexical-let, that does let but sets to
> the provided values just as lexical-set! does...?  Well, that's how I
> see it, anyways.

no, let does no assignement AFAIK.

> And while your arguments seem quite reasonable (decide for each access
> of a symbol between lexical and dynamic), I think this creates a
> superfluous amount of confusion and "just" switching for certain
> variables to lexical binding within the scope of a lexical-let seems to
> me the better solution.

Aha, now I understand what you want lexical-let to mean.
If you are explicit about each variable access how can that be confusing?
Possibly confusing is if you have to examine the complete enclosing context for
lexical-let's.

> What's about this:
>
> (defun test () a)
> (let ((a 1))
>   (print a) ; 1
>   (print (test)) ; 1
>   (lexical-set! a 2)
there is only one variable `a' in my mental model,
so this changes the value of the only `a' and all
subsequent expressions accessing `a' are thus affected.
The same as if you had written `(set! a 2)'. Dynamic
and lexical only differ in how free variables in
procedures are bound.
>   (print a) ; 1?
no, (print a) => 2
>   (print (test)) ; 1
no, there is only one `a' and its value is 2 here
>   (print (lexical a)) ; 2
>   )
> 
> I don't think it's good to have to "completely seperate" variables a and
> (lexical a).

I don't understand what you mean. My proposal is to have one kind of variable
and two kinds of access.

> And besides, here there's no way to decide that no fluids
> at all are needed for a, as the let construct itself (except the
> references following) still creates a with-fluids* call.

For the calls above all the dynamic accesses can be determined statically.
Lexical accesses can always be determined statically. Thus all accesses in this
example can be determined statically and can be compiled to a location
dereference (either read or write). Nothing in the semantics is inherently
inefficient.

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

iEYEARECAAYFAkpogK0ACgkQp/VmCx0OL2x4JACgwYR+48aAHTjMu1S6H7Dw4utR
YzoAn3hMwhEadhlrAw7a06gWZBEoDWQX
=DkN6
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]