[r6rs-discuss] Implicitly Concurrent Scheme
agj at alum.mit.edu
Sun Nov 1 22:36:48 EST 2009
| 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>
| > 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
You could have further gradations of optimization by only optimizing
calls having even numbers of arguments. I think this line of inquiry
| 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
More information about the r6rs-discuss