[r6rs-discuss] Implicitly Concurrent Scheme

[Aubrey Jaffer]

 | Date: Wed, 28 Oct 2009 14:16:05 -0400
 | From: "Aaron W. Hsu" <arcfide at sacrideo.us>
 | 
 | On Wed, 28 Oct 2009 13:26:13 -0400, Marc Feeley <feeley at iro.umontreal.ca>  
 | wrote:
 | 
 | > The work of Katz and Weise on the semantics of continuations in a
 | > parallel setting (which I describe in my thesis) is also relevant
 | > to this discussion.
 | 
 | So, one of the real questions I have now, which I am not really
 | sure I fully understand is: how much of the current specification
 | specifically makes it impossible to do parallel optimizations?

They are not impossible, just theoretically undecidable and very
difficult in practice.

 | That is, in R6RS, what things would specifically need to change in
 | order to implicitly or explicitly make it possible to do effective
 | parallelization?  I'm not talking about making it explicitly
 | possible to always execute things concurrently unless that is the
 | minimum restriction necessary to make it possible to execute
 | certain things concurrently; I'm not sure it is.

The change from portably-repeatable to concurrently-repeatable makes
parallel optimizations easy.

You could eliminate half of the parallel optimizations by making `map'
serial (but unspecified order) and strict arguments concurrent; or by
making `map' concurrent and strict arguments serial (but unspecified
order).

You could have further gradations of optimization by only optimizing
calls having even numbers of arguments.  I think this line of inquiry
is unenlightening.

 | Without changing the behavior of the language, and permitting all
 | code already written to continue to run, what would these changes
 | look like?

There is a significant body of existing code which is not
portably-repeatable.  It runs with the particular
order-of-evaluation-of-arguments of one or two implementations, but
would break with a different order.  Demanding that concurrency
optimizations work on code which isn't even portable under RnRS is
unreasonable.