This page is part of the web mail archives of SRFI 15 from before July 7th, 2015. The new archives for SRFI 15 contain all messages, not just those from before July 7th, 2015.
Lars Thomas Hansen <lth@xxxxxxxxxxx> writes:
> One difference is that the SRFI will work also on lexically visible
> variables whereas your spec implies that references and assignments to
> lexically visible variables are not subject to the lookup mechanism
> (taking "non-local" to mean "global" in your spec).
I intended "non-local" to mean "non-lexically visible".
A plausible modification is that if the closest binding (lexically)
of an identifier is a fluid-let, then the identifier should be
resolved dynamically.
Still, I won't say that is the "correct" (cleanest/best) semantics.
> In the event that the program executes in several dynamic
> scopes simultaneously (as in a parallel system), then no use
> of FLUID-LET to override a variable in one scope may affect the
> value of that variable as observed from a different scope.
Perhaps add something like:
unless the latter scope is created so that it inherits dynamic
bindings from the former, and there is no local fluid-let active
in the latter scope.
Olin Shivers <shivers@xxxxxxxxxx> writes:
> Gambit's dynamic vars allow anyone who can *write down the name* of
> a dynamic var to access its dynamically bound value. I would argue that's too
> uncontrolled. Also, you have to introduce a whole new linguistic mechanism,
> whereas fluid cells just require some new primitive procedures, with
> no actual language-level hacking.
On the other hand, the nice thing about about "the Gambit approach" (?
I couldn't find anything about it in the Gambit-C manual online) is
that it doesn't require people to write (fluid X) for what is "get me the
current value of X". In Kawa, a variable reference (or assignment)
can expand to a call to a general getter or setter procedure, so you
actually don't need extra "language-level hacking" to have "X"
magically expand to "(fluid X)". (I'm in the process of putting together
a srfi that relates to this.)
--
--Per Bothner
per@xxxxxxxxxxx http://www.bothner.com/~per/