[r6rs-discuss] Implicitly Concurrent Scheme
antonio.vieiro at gmail.com
Sun Nov 22 18:06:08 EST 2009
A programmer that relies on unspecified order of evaluation is prone to
errors, and must await unexpected results. Whether these follow the
serialization constraint or not is of no importance, as the final result
he may get will depend on the Scheme implementation he uses.
In  depending on the order of evaluation, Example 3 may give the
following results in serializable order:
'((A 2)) ; Sequential SS1
'((A 3)) ; Sequential SS2
So the programmer may get '((A 2)) in one implementation and '((A 3)) in
Whereas in parallel evaluation the results might be
'((A 2)) ; Parallel PS1
'((A 1)) ; Parallel PS2
And there's no problem in that, I think: again the programmer gets
different results in different implementations, so what?
By removing the serialization restriction we're just *increasing* the
number of results you can get when you rely on unspecified order of
And these new results, I think, are as predictable as the ones the
programmer can get with the serialization constraint (as  shows).
There're more results now, but these new results are not less
predictable (nor less clear) than the previous set of results.
Programmer ammunition against these new results (as against the
unexpected behaviour of unspecified evaluation) is 'begin', as has
The only advantage I can think the serialization constraint offers is to
make formal reasoning about the language easier, so one can build an
operational semantics for Scheme (as in ) more easily without
worrying about concurrency (the serialization restriction is taken into
account in , though).
But then (if so) this is a benefit for the academic community, not for
the user community.
Aaron W. Hsu escribió:
> This restrictions ensures two things:
> 1) The behavior of the expression in question will never exhibit
> behaviors that cannot be reproduced in a single-threaded environment.
> 2) The programmer need not constantly consider issues of threading for
> every function call, which must happen in the case of ICS.
> In other words, removing the restriction makes programs less clear, more
> prone to problems, and hence, less reliable, without actually
> introducing anything new for the user. This is all for the sake of
> making it easier to concurrently execute procedure calls for the
> implementors. I can't see how it is worth it.
> Aaron W. Hsu
More information about the r6rs-discuss