This page is part of the web mail archives of SRFI 15 from before July 7th, 2015. The new archives for SRFI 15 contain all messages, not just those from before July 7th, 2015.
>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