Local functions

[Stephen Colebourne]

On 10 February 2010 22:35, Alex Buckley <Alex.Buckley at sun.com> wrote:
> I agree demarcation of/restrictions on parallel code are orthogonal to
> lambdas and function types. A glance at the FindBugs bugs for
> multithreaded correctness shows little the language could internalize to
> make the body of a lambda expression correct by construction. (Short of
> horrendous type system "enhancements".)
+1

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

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

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

Again, we still need some REQUIREMENTS for lambda to understand why on
earth we're making this language change!!!!

> The Lambda strawman is at odds with
> some of those restrictions; resolution is forthcoming.

I'm looking forward to it with trepidation.

Stephen