Too terse and too alien?

[Alessio Stalla]

On Tue, Jun 1, 2010 at 11:38 PM, Neal Gafter <neal at gafter.com> wrote:
> On Tue, Jun 1, 2010 at 2:26 PM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>>
>> On Tue, Jun 1, 2010 at 11:02 PM, Neal Gafter <neal at gafter.com> wrote:
>> > 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?
>
> In my experience, yes, virtually always.

Really? I forgot to mention no local variables, since Java doesn't have let.
I can come up with reasonable counterexamples:

sorting people by surname and name (middle name omitted for brevity :D):

Collections.sort(people, #(Person p, Person q) (
  p.getSurname().compareTo(q.getSurname()) != 0 ?
  p.getSurname().compareTo(q.getSurname()) :
  p.getName().compareTo(q.getName()) ));

vs

Collections.sort(people, #(Person p, Person q) {
  int surnameComparison = p.getSurname().compareTo(q.getSurname());
  return surnameComparison != 0 ? surnameComparison :
p.getName().compareTo(q.getName())
});

processing all event handlers in a list:

Collections.map(list, #(EventListener e) {
  try { e.handle(event); } catch(Exception e) { log.error("Exception
while processing listener", e); }
});

accessing non-thread-safe objects in a collection:

Collections.map(list, #(Object o) {
  synchronized(o) {
    return o.something(...);
  }
});

etc. these are really just simple examples.

>>
>> 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.
>
> Right.  Those other contexts are ones in which transparency is more
> important, and yielding a result value is rare.

Fair enough.

>> > 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).
>
> Yes, that is the current state of the proposal, which is why it's valuable
> to address it now.

Ok, I misinterpreted "future extension".

-- Alessio