Lars Thomas Hansen <xxxxxx@ccs.neu.edu> 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 <xxxxxx@ai.mit.edu> 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
xxxxxx@bothner.com   http://www.bothner.com/~per/