[r6rs-discuss] Implicitly Concurrent Scheme

[Thomas Lord]

On Thu, 2009-11-12 at 14:21 -0500, Aubrey Jaffer wrote:
> I am suggesting the following restriction be *removed* from the
> "Procedure calls" section of RnRS:
> 
>     _Note:_ Although the order of evaluation is otherwise unspecified,
>     the effect of any concurrent evaluation of the operator and
>     operand expressions is constrained to be consistent with some
>     sequential order of evaluation.  The order of evaluation may be
>     chosen differently for each procedure call.

Wow.  That's an interesting situation.

I hadn't realized, until you pointed it out that Scheme
has a system of arbitrarily nested transactions for 
mutable memory and I/O.   I mean I knew that "consistent
with some sequential order..." language but never really
thought about it much.

I'm of two minds.

Mind one:

Given the unconstrained nature of side-effects in the
language, I think taking that out would just make a mess.
I don't think it yields a language anyone would really
want to implement in a highly parallel way.   Locking
on an arbitrary graph of mutable objects and ports?  No 
way!

Worse, I think if you really want a language that can
be parallelized effectively, side effects have to be
constrained to such an extent that I'm not sure what
we'd be left talking about is reasonably called "Scheme"
anymore.

Mind two:

No, wait, you're completely correct.   A good compiler
might very well be one which only tries to parallelize 
operator and operand expressions which can be statically
proved to not interfere.

If I want those "effect-constrained" features for deeply
parallel code, I need only arrange that the effects of the
code in question are statically apparent and orthogonal.

Indeed, that would be a graceful way to ensure that Scheme
grows in the number of "paradigms" it can usefully express.

----------

I think mind two has the better notion, but it is a 
bit hard to prove.


-t