>I like fluid-let.  My claim is that fluid-let is more powerful and
>more general than suggested by the srfi-15 specification.  The
>question is: Do we want to specify fluid-let in a way that does not
>work (or at least does not seem very appropriate) in the precense of
>threads, or do we want a different specification?  I proposed a
>different specification.

I misunderstood your previous message.

>Specifically, can an implementation that follows the model I proposed
>(for example Kawa) claim to be consistent with this srfi or not?
>(Does it matter that Kawa does not yet implement full call/cc, and
>when/if it does, will probably not do so by default?)

For reference, your proposal is:

>(see http://sourceware.cygnus.com/ml/guile/1999-03/msg00023.html):
>
>  Each thread has an association list of fluid bindings.
>  When fluid-let is evaluated, it conses up a new association to the
>  front of the list.  That becomes the current fluid binding
>  association list while the body of the fluid-let is evaluated.
>  The old list is restored when the fluid-let finishes.
>  (This can be implemented with the appropriate dynamic-wind.)
>  When a new thread is created, it initializes its fluid
>  binding list with the *current* list from the parent thread.
>  Thus all bindings are initially shared.  When a non-local
>  variable is evaluated, the evaluator searches the current thread's
>  fluid binding list, and finds the first binding for the given name.
>  If none, is found, the global binding is returned.
>  When a set! is evaluated, it also searches the fluid bindigs list
>  of the current thread, and modifies the first association whose
>  name matches.  If there is none, the global binding is modified.

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).

Were you to modify your spec, simple analysis would be sufficient to
avoid doing the search for any other lexical variables than the ones
fluidly bound (almost none) but that kind of analysis would be outside
the capability of most interpreters.

I could modify the SRFI to exclude lexically visible variables, at
the cost of precluding a portable implementation, but I'd prefer to
keep that capability.

For global variables (not shadowed), and with a single thread, I think
the SRFI and your spec have the same behavior.  I think that is also
true for call/cc based threads.

As to whether the SRFI is inappropriate for real threads.  What you are
getting at, presumably, is a situation like:

	(define x 10)
	(spawn (lambda ()
		 (fluid-let ((x 20))
		   ...)))
	(spawn (lambda ()
		 (fluid-let ((x 30))
		   ...)))
	(define y x)

and the question is, if fluid-let is defined in terms of overriding
variables in a dynamic scope, what value does y have when x is
simultaneously overridden in several scopes?  We'd like to ensure that
y=10.

For call/cc threads this is easy, and the SRFI is unambiguous: the right
thing happens.  For real threads the issue is thornier because the SRFI
does not talk about control being in more than one dynamic scope at a
time (nor does Scheme have such a notion).

I propose that we add the following language to the SRFI:

	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.

That allows techniques like deep binding (modulo the issue of lexical
variables) and it may allow others.

What do you think?

--lars