Syntax decision

Stephen Colebourne scolebourne at joda.org
Sat Oct 1 03:38:11 PDT 2011


On 1 October 2011 01:25, Brian Goetz <brian.goetz at oracle.com> wrote:
> The only thing going for the strawman syntax was that if you squinted
> and pronounced # as "method", it looked like the method declaration
> syntax.

Oh and it was the most "logical", as you say yourself.

Basically, the strawman syntax was derived from FCM. I introduced the
syntax with an example of a comparator (formatted on multiple lines)
with the comment "This syntax is termed an anonymous inner method, and
is a logical extension to the anonymous inner class concept".

And further described as:

"With FCM, we chose to use the # symbol as our key syntactic element.
There were a number of reasons. Firstly, # is unused in Java at
present. This means that there are no conflicts within the parser,
simplifying the proposal. It also means that someone reading the
resulting code doesn't have to think about what the symbol means
(unlike ?, <, > or : for example). The # has been used by Java
developers before however, as it is used in Javadoc. It has been
pointed out that in most, if not all, cases, the parser could work out
the meaning of the code without the use of the symbol at all. This is
true, but a key feature of Java is readability. We believe that in
this case, the extra symbol adds to the readability by clearly
identifying the method syntax. This is important for inner methods
which are likely to be running in another thread, hence the # acts as
a kind of warning."

Thus the syntax picked itself - start from method references
String#concat. treat #foo as being this#foo where #foo is a reference
to foo, thus # on its own is a reference to some code without a name
(anonymous). Then, add method arguments and block.

The # also acted as a very visual "capture" when searching for where
the "return" statement returns to, something that I find harder with
an arrow. The importance of the return point depends like much of this
on whether you believe that expression or multi-line statement lambdas
will be most common.

Note that #()(expr) was never in FCM and I never supported it (it
looks and reads very badly), but I would have supported #() expr.

To emphasise, the # linked the method reference and inner method
(lambda) parts together for learners, something which has been lost
now.

I also found, as Stuart did, that the {-> expr} and {-> stmt;} forms
differing only by a semicolon was a recipe for trouble.

Personally, I find the selected syntax OK, but not great, except in
the x -> expr form. Thats because I dislike the way that the argument
brackets blend into the method parameter brackets when passing to a
method as in sort((a,b) -> a - b). I always find its the blending of
similar characters that is hardest to read, and why # was useful
punctuation. Thats also why I might well prefer a Ruby-like sort(|a,b|
a - b), because the characters do not blend in the same way.

But anyway, I'm sure we'll get used to it.

Stephen



>  But, it was broadly hated for so many reasons, including:
>  - Some people just hated the #, it felt like being hit over the head
> with a hammer labeled "watch out, something new and different here!"
>  - Some people had a hard time seeing #(x)(x) as one expression, rather
> than two
>  - Visual confusion with casts.
>
> While all the options had supporters and detractors, strawman elicited
> the strongest negative reaction from its detractors.  If you look at the
> "too terse and too alien" thread from June 2010, you'll see some initial
> reactions from this group.  While people later softened their stance
> (likely through familiarity), the negative reactions were just too strong.
>
> Basically, while it might have been the most "logical" syntax, we're not
> logical beings.
>
>


More information about the lambda-dev mailing list