Local functions

[Jesse Kuhnert]

That sounds completely reasonable to me .. (esp after recently reading
http://prog21.dadgum.com/61.html - which supports the idea that
parallel sorting algorithms shouldn't be done automatically)

On Thu, Feb 11, 2010 at 12:21 PM, Osvaldo Doederlein <opinali at gmail.com> wrote:
> 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
>
>