[Top][All Lists]

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

Re: Elisp lexical-let

From: Daniel Kraft
Subject: Re: Elisp lexical-let
Date: Wed, 22 Jul 2009 21:24:31 +0200
User-agent: Thunderbird (X11/20070425)

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

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.


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

reply via email to

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