[srfi-15] FLUID-LET wrapup

[Lars Thomas Hansen <lth@xxxxxxxxxxx>]

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