[r6rs-discuss] Implicitly Concurrent Scheme
lord at emf.net
Fri Nov 13 16:38:23 EST 2009
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.
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
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"
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.
More information about the r6rs-discuss