Re: Elisp lexical-let

[Daniel Kraft]

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; and at least in my Lisp code, setting is mostly done with 
let's, so at the same time as the "binding".

So what you propose would then be to have a (lexical sym) for 
referencing and (lexical-set! sym value) for setting in lexical scope -- 
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.

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.

What's about this:

(defun test () a)
(let ((a 1))
  (print a) ; 1
  (print (test)) ; 1
  (lexical-set! a 2)
  (print a) ; 1?
  (print (test)) ; 1
  (print (lexical a)) ; 2
  )

I don't think it's good to have to "completely seperate" variables a and 
(lexical a).  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.

Yours,
Daniel

PS: From a performance point of view, I guess that the void checks on 
each variable access are far more expensive than the 
fluid/dynamic-scoping business.  But I'll report on this (performance) 
maybe in a seperate posting when I've done some experiments and real 
data as well as suggestions.

--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri