Preparing for the 0.2 draft

[Neal Gafter]

On Mon, Feb 1, 2010 at 5:18 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> Anything that makes racy code appear to be plain
> and innocent makes me nervous: Ideally, for
> the sake of parallel execution, we'd disallow automatic
> sharing of locals and automatic elevation of "this", "return"
> or "break" to enclosing scopes. Because of course,
> when run in parallel, the lexically enclosing scopes
> have little to do with actual execution context.  For
> data, these are possible races,

Parallelism is orthogonal to whether or not lexically enclosing scopes
"have to do with" the execution context of a lambda.  Racy code arises
from the intersection of mutating data and concurrency without
synchronization.  That, too, has nothing to do with whether or not the
concurrency is expressed using higher-order code (i.e. lambdas) or
imperative code.  Conflating these concepts in the language design
threatens to undermine their utility.

> and for control they are possible crazinesses (returns to nowhere, etc).

We've already shown that the ability to express nonlocal control
(return, for example) can lead to very natural and expressive
concurrency APIs, and the evidence from the use of such APIs (e.g. in
Scala) is that the kind of errors you're concerned about don't arise
in practice.