[r6rs-discuss] Implicitly Concurrent Scheme

[Antonio Vieiro]

Hi again,

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 [1] 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 
another.

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

And these new results, I think, are as predictable as the ones the 
programmer can get with the serialization constraint (as [1] 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 
always been.

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 [2]) more easily without 
worrying about concurrency (the serialization restriction is taken into 
account in [2], though).

But then (if so) this is a benefit for the academic community, not for 
the user community.

Cheers,
Antonio


[1] http://okmij.org/ftp/Computation/serialization.html
[2] http://lambda-the-ultimate.org/node/971

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
>