How about a combo?

[Howard Lovatt]

Hi Pavel,

I don't have a strong preference between my syntax:

#< *ReturnType*( *ArgumentTypes* ) throws *Exceptions* >


Your syntax:

Function< *ReturnType*( *ArgumentTypes* ) throws *Exceptions* >


Or Gernot Neppert (copied) syntax:

lambda< *ReturnType,* *ArgumentTypes,* throws *Exceptions* >


They are all consistent with current Java (to a much greater degree than
other suggestions), they nest, and you can have arrays of them. Gernot's
syntax is the same as that proposed by JSR 292 for method handles, except
that he uses 'lambda' and they use 'MehodHandle'. (At least I think it is,
JSR 292 is in a state of flux. I have copied John Rose so hopefully he will
be able to enlighten me.)

The choice between them would really be a matter of style. I chose to use #
for two reasons:


   1. It was used in the strawman
   2. It reminds people that this is not a normal class and that they can't
   write one of these themselves

The choice of using round brackets instead of commas was to be consistent
with normal method declarations and was the syntax used in the strawman.

With regard to Neal's comments (copied); I am like you, at a loss to see why
he cannot understand the proposals. All the proposals, not just those that
use <>, are after all relatively minor syntax variations on each other.
Stefan Schulz (copied) was able to write a grammar for all the proposals, so
clearly he understood them! I didn't find Neal's response to you very
enlightening, he said "He [Howard - Me] invents the concept of varargs
generics just for this purpose" and "To me, his [Howard - Me] proposal looks
like a mess of muddy thinking".  With regard to "invents the concept of
varargs generics", all the proposals have to deal with a variable number of
arguments and exceptions (that's what methods have) and so does MethodHandle
(which as noted uses <> also). With regard to "muddy thinking", why is
putting <> round some syntax already proposed (strawman) to fix up the
problems of consistency, nesting, and arrays muddled?

So I don't get why Neal thinks his comments advance the debate about syntax
in general or advance the cause of his preferred syntax, surely lambda dev
is the ideal place for people to discuss syntax suggestions? And it is not
the place "to take your bat home" (good Cricketing term that means "to get
upset") if someone disagrees with your preferred option.


 -- Howard.

*On Fri, Mar 19, 2010 at 5:53 PM, Pavel Minaev <int19h at gmail.com
<http://mail.openjdk.java.net/mailman/listinfo/lambda-dev>> wrote:*

*On Fri, Mar 19, 2010 at 7:49 PM, Neal Gafter <neal at gafter.com
<http://mail.openjdk.java.net/mailman/listinfo/lambda-dev>> wrote:*

>* On Fri, Mar 19, 2010 at 5:53 PM, Pavel Minaev <int19h at gmail.com <http://mail.openjdk.java.net/mailman/listinfo/lambda-dev>> wrote:*>>**>>* > Other than that, I can't make heads nor tails of this proposal.*>>**>>* Do you refer to the type inference bit, or to the proposal in general?*>>**>>* If the latter, can you be more specific as to what seems troublesome?*>**>* All of it.  I can't be more specific because I'm having trouble figuring out*>* how the parts of the proposal are supposed to fit together.*
I must admit that I am completely stumped. In terms of syntax, I
thought that I had explained it unambiguously, especially given the
examples, which don't leave much to speculation. If a more formal
grammar is still desired, I can certainly come up with it, but it
doesn't look like it is what is causing issues with understanding
here. Correct me if I'm wrong.

With respect to how "parts fit together" - I don't understand the
problem at all.

On one hand, there is a function type definition syntax and semantics
taken from Howard's angle brackets proposal - calatogued
(athttp://docs.google.com/View?id=ddhp95vd_15gqnv8xqm) as #13 - and
modified by me by replacing # with a reference to a pseudo-class
java.lang.Function.

Then there is a lambda definition syntax and semantics taken from your
arrow proposal - catalogued as #5 - and modified by me by dropping ->
when body of lambda is expression rather than block, and by prefixing
the parenthesized parameter list with an explicit return type.

I do believe that those two proposals thus modified and combined make
most sense - most "Java-like" in appearance, if you want - in their
respective categories. And, so far as I can see, the categories
themselves are fully orthogonal, in a sense that one can easily "pick
& match" separately. In what way do you expect to see them fit
together?

Further references:

Howard's proposal (which already replaces # with a pseudo-class) - I
only referenced the function type part of that, not the lambda
definition part:http://mail.openjdk.java.net/pipermail/lambda-dev/2010-March/001135.html

Your proposal - I only referenced the lambda definition part of that,
not the function type
part:http://mail.openjdk.java.net/pipermail/lambda-dev/2010-February/000610.html


Does this help?