Re: dynamic Bindings; thread-state

[mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]

Per Bothner <bothner@cygnus.com> wrote:
> > Unless I missed something, FLUID-LET can't make top-level bindings which
> > should exist for each and any thread, and about which the code which
> > creates some new thread doesn't need to know.

> Regular define seems to do what you want.

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

> If a thread does not do fluid-let, it gets the binding from its parent.

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. As a trivial example (which may or may not be useful in practice,
that's not the point here), think of a module giving the clock-time which
has passed since a thread was created, and which doesn't demand any explicit
notice upon thread-start. Generally, any kind of resource which is supposed
to exist in every thread, but about which the "main code" shouldn't have to
know, benefits from an expressive implicit initialization mechanism.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>