Preparing for the 0.2 draft

[Doug Lea]

Sorry again that I've been swamped lately and haven't
had time to offer much constructive feedback. But here's
a reminder about the some of the needs/wants we have of
lambdas wrt parallel execution.

Among the main goals is to make it easier to
correctly and efficiently perform operations such as apply,
map, reduce to all elements in an aggregate -- usually an array
or collection. The "correctly" part (increasingly known
by the crummy term "deterministic parallelism") means
that you do this while avoiding unintentional races/interference.
But without more heavy language mechanics than is
possible (or desirable) in Java, you cannot
preclude all racy constructions. So we are left with
language and API choices that make non-racy usages easy
and natural, and racy ones less so. (Aside: this
has nothing to do with pure functional programming.
We equally like "apply(addOne, myArray)" and
"map(plusOne, myArray)").

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, and for control they
are possible crazinesses (returns to nowhere, etc).

So if any of these things are made possible (which
I'm sympathetic to, or at least tolerant of exploring),
they must be made bug-avoiding when used in parallel
contexts. Not sure how.

-Doug