Re: dynamic Bindings; thread-state

[Per Bothner <bothner@cygnus.com>]

> What I meant is that the same top-level name denotes a different binding
> in each thread, in contrast to regular DEFINE, which denotes the same one
> in each thread.

Since Scheme bindings are not first-class, what you say is open to
interpretation.  What is a "binding"?  We can interpret it as we
see fit.

If you re-read my original "specification" of fluid-let, you will
see that define does *not* necessarily define the same binding in
each thread.

> FLUID-LET is necessarily related to control flow, which
> restricts its usefulness to cases where the availability of a binding is
> temporary and explicit.

Scheme does not have "temporary and explicit" bindings.

> Though sometimes that's what I want, sometimes I want each thread (whether
> old or new) to start with the same original value, independently on the state
> of system, sometimes I want to allocate a fresh object for each thread, and
> so on - and I want to be able to hide even the existence of such a binding
> in a module, without bothering new threads or their creators to perform a
> FLUID-LET.

Well, if you define the problem so fluid-let is not acceptable, well
then I guess fluid-let will not work for you.  But if you have a real
problem, and don't insist on restricting the tools you can use, then
I suspect fluid-let will solve most of them relatively cleanly.
Or perhaps not.  I guess we need more experience.  In any case, the
latest Kawa snapshot (1.5.92) now supports thread-safe fluid-let,
and I consider the problem solved (efficiency issues aside), until I
see real evidence of a real problem.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner