Optional brackets around lambda expression

[Collin Fagan]

Instead of removing the parens from the lambds can we remove the parens from
the method call?

So this:

list.filter(#(Foo t){ t.length() > 3})
    .map(#(Foo t){ t.barCount})
    .max();

becomes this:

list.filter#(Foo t){ t.length() > 3}
    .map#(Foo t){ t.barCount}
    .max();

My first thought was that this would only be valid for methods that take a
single lambda. (a varargs of lambdas?)

More examples:

Student Filtering Multi-line:

students.filter#(student){
    if (student == null || student.getName() == null){
        return false;
    } else {
        return student.getName().equals("Smith");
    }
};

Student Filtering Single Line:

students.filter#(s){ s != null && "Smith".equals(s.getName())};

These examples also show the elimination of the }); construct that I don't
particularly care for.

Is it's possible to use the strawman without the # prefix?

students.filter(student){
    if (student == null || student.getName() == null){
        return false;
    } else {
        return student.getName().equals("Smith");
    }
};

That looks like you are implementing the method in-line, which I guess is
kind of what you are doing anyway.

I think one might be able to get away with this in the other syntax options.

BGGA

students.filter{ student ->
    if (student == null || student.getName() == null){
        return false;
    } else {
        return student.getName().equals("Smith");
    }
};

Just an idea.

Collin

On Fri, Jun 17, 2011 at 5:14 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

> On 06/17/2011 10:57 AM, Maurizio Cimadamore wrote:
> > On 17/06/11 09:49, Bob Foster wrote:
> >> Maurizio Cimadamore wrote:
> >>> On 17/06/11 07:59, Reinier Zwitserloot wrote:
> >>>> Er, right. This redmond variant syntax of Ali Ebrahimi:
> >>>>
> >>>>
> >>>> a, b, c ->    expression
> >>>>
> >>>> cannot work, as far as I can tell, in the current parser architecture
> of
> >>>> javac and ecj, and attempting to work around it or fix the parser is a
> >>>> massive undertaking. I think - experts, please chime in!
> >>>>
> >>> This is right - you can remove the parenthesis around the args when
> >>> there is just one argument (and there is no explicit type on the lambda
> >>> parameter); in that case the grammar would be something like:
> >>>
> >>> IDENTIFIER '->' ...
> >>>
> >>> In all other cases you need enclosing parens, as in:
> >>>
> >>> (a,b,c) ->   body
> >>> (Type1 a, Type2 b)->   body
> >>>
> >>> [the above can be disambiguated from a cast or a parenthesized
> >>> expression because of the trailing ')->' sequence, which would be
> unique
> >>> to lambdas].
> >>>
> >>> Another alternative, for those who don't like surrounding parenthesis,
> >>> would be to use a special prefix (as in SoTL or Strawman), as in:
> >>>
> >>> #a,b,c->body
> >> I'm not going to pretend to be a parsing expert, particularly if it's
> >> defined in terms of the changes can be easily made to the the javac
> parser,
> >> but...
> >>
> >> This would be no problem for a PEG. Isn't the whole idea that you can't
> look
> >> ahead a bit somewhat outmoded?
> >>
> >> Bob
> >>
> > Of course you can lookahead; but certain expressions, as pointed out
> > will remain ambiguous:
> >
> > process(x, y, z, a, b, c, d ->   a);
> >
> >
> >
> > Which means the parser will have to choose one for you.
> >
> > Maurizio
>
> Foo foo = #a,b,c->body
>
> is ambiguous too
> because #a can be a method reference and the following comma
> the comma of the initializer.
>
> Rémi
>
>
>