Local functions

[Alex Buckley]

Stephen Colebourne wrote:
>> That said, I am happy to prioritize parallel use cases over non-parallel
>> use cases. Sun is not aiming to add lambdas to allow control abstraction
>> or DSL building, but rather to support FJ ParallelArray and APIs like
>> it.
> 
> And the whole use case category of functors and predicates operating
> on regular collections? Abandoned? Only accessible via a second class
> syntax?

"APIs like it" is a comprehensive term. You mention predicates; any 
filter operation, be it in ParallelArray or the most sequential 
collections API, is an obvious candidate for lambdas.

> I didn't think thats what lambda was about. But then we don't have any
> REQUIREMENTS so we can't judge.

Goals at http://blogs.sun.com/mr/entry/closures.

I am not interested in a philosophical debate, but the kind of 
requirements you mean are for frameworks, not languages. (Except for 
dull things like "Must support Unicode 5.0".) For example, I don't 
recall requirements for BGGA, on which you based JCA.

>> 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.

Thanks for your view. The Java ecosystem is a big place. This project is 
interested primarily in supporting parallel execution. If you are 
interested primarily in something else, there are other projects for you.

Alex