Local functions

[Osvaldo Doederlein]

2010/2/10 Stephen Colebourne <scolebourne at joda.org>

> > So I'm fine if lambda bodies are restricted along the lines Doug
> > suggested. ("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.")
>
> It sounds like the tail is wagging the dog. And this could wreck the
> whole lambda change. I posit that Parallel Arrays and their ilk will
> *not* be the major usage of a suitably designed language change. Most
> developers simply don't need massively parallel type operations.
> Writing a typical web application, e-commerce app or desktop app
> doesn't benefit from Parallel Arrays - they are a specialist feature.
>
> While I understand the problem (Sun wants to add parallel arrays to
> the JDK but can't due to interface explosion and ugly inner class
> syntax), this needs to be treated as just one use case, that is
> relatively minor.
>

#{+1}, #{+1}, #{+1}, #{+1}     // Lambda agreements, in parallel on a
quad-core

Even if Parallel Arrays _are_ a major use case, I don't think the lambda
spec should provide any level of baby-sitting for developers, and especially
not anything that creates restriction or even harder usage (requiring extra
modifiers) for other use cases.

If a programmer creates a parallel computation with lambdas that share some
mutable variable and race on it, just let that program explode in the
programmer's face. Next release FindBugs will certainly have a new rule that
emits a warning for such code, and that's all. (If we are kind enough, maybe
javac itself will have such [optional] warning.)

Parallel Array will be used mostly by expert programmers, and mostly for
algorithms with critical performance requirements. Unless we consider
further language sugar, e.g. auto-parallelization (accum = 0; par-for (x:
elems) {accum += x.something()} => emits both ParallelArray code and a
lambda) but this is not in the roadmap for SE7 and if we do that in the
future, it's a different design setting, javac would have much more control
(will typically generate the lambdas) so it will just generate the "right"
code. In fact, I expect this to be a realistic roadmap, if not for Java 8+
then certainly (and much sooner anyway) for other languages like Groovy,
Scala, Clojure or Fortress. So, in the long term I see Parallel Arrays as a
"raw" low-level API that will be used directly mostly by experts / library
writers / language designers... even with lambdas. Most programmers won't
need Parallel Array within the SE7 lifecycle; and a few years down the road,
when SE8+ is available (not to mention other languages), most programmers
will need it (unless we already have graphene-based 100GHz CPUs, he he) but
then they will jump straight to higher-level syntax.

A+
Osvaldo