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.
The draft period for this SRFI is almost up. The issues that have been raised are: (a) this is the wrong kind of system (Shivers, Lucier) (b) the spec does not address actual concurrency (Bothner) As to (a), I don't necessarily disagree with Shivers and Lucier, but as I have explained at length in other messages, my goal was to codify a useful existing practice, and I am not going to address that issue further. As to (b), the trouble with the spec is that it does not address the effects on the dynamically bound variable outside the dynamic scope of the binding while some thread is inside the dynamic scope of the binding. I proposed adding the following text to the proposal to deal with concurrent execution: 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. and Bothner suggested amending that with the following to deal with independent threads of control that inherit the dynamic environment of their creator (by my understanding the dynamic environment in effect at the time of thread creation): 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. It seems to me that the use of "unless" is not warranted, because there is no contradiction between this second amendment and the first amendment. The first amendment talks about what happens if we use FLUID-LET with concurrent execution. The second amendment talks about what happens if we share dynamic bindings and don't use FLUID-LET. I think the following says the same thing as the proposed second amendment: A dynamically bound variable v is said to be _shared_ among dynamic scopes S1, S2, ..., Sn, in all of which v is visible, if an assignment to v in some Si is observable in all the Sj. Systems that allow the programmer to create shared dynamically bound variables among concurrently existing dynamic scopes must respect the sharing. That seems sort of trivial; is there really good reason to leave it in? I am tempted to leave the spec as it is (without either of the amendments) with an annotation to the effect that the spec does not handle systems that have real concurrency. If we leave a discussion of concurrency in, then a credible sample implementation for a concurrent system ought to be supplied, and the overall effect will be to obscure a simple mechanism with a bunch of baggage to handle systems that have real concurrency. Instead, I think it may be better for a compatible SRFI for FLUID-LET in the presence of concurrency to be submitted at some later time. Debate on the above points? Per? --lars