Too terse and too alien?

Alessio Stalla alessiostalla at gmail.com
Tue Jun 1 14:26:54 PDT 2010


On Tue, Jun 1, 2010 at 11:02 PM, Neal Gafter <neal at gafter.com> wrote:
> On Tue, Jun 1, 2010 at 12:35 PM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>>
>> I agree to having only a single syntax, #(int i) {return i * i;}. An
>> extra return won't make much difference, and special-casing closures
>> with a single expression as their body makes it slightly inconvenient
>> to change them in case you later need to have more than an expression.
>> Consider also that Java is not a functional language, and its
>> expressions are limited to math, assignments, comparisons, and ternary
>> conditionals; if, try-catch, switch, etc. are not expressions, so I
>> think single-expression closures will be seldom used anyway.
>
> I think single-expression closures will be the most common form, especially
> in the context of the kinds of aggregate (possibly concurrent) operations
> that is cited as the primary motivation for adding closures at this time.

Are those aggregate operations expected to be usually limited to
simple math, assignments, ternary ifs and method calls with no
try-catch, switch, loops? I don't think so. I also think other
important use cases for closures are the java.util.concurrent API, to
execute whole blocks of code asynchronously, and event handlers, and
both usually consist of much more than a single expression.
To me, the no-return variant seems like an attempt to mimic functional
languages, which usually don't need an explicit return. However,
there's a reason for them not needing it: in most functional
languages, everything is an expression and thus returns a value,
including complex control structures. Not so in Java.

> An extra return does make a difference, particularly if we ever hope to more
> fully support transparency ala BGGA in a future extension.

Well, AFAIK return is mandatory for multiple-statement closures, with
the semantics of returning a value from the closure, so this already
makes them incompatible with the BGGA proposed behaviour (which I
don't like btw, but that doesn't count).

Cheers,
Alessio


More information about the lambda-dev mailing list