[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: let-fluid problem
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
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.)