How about a combo?

[Pavel Minaev]

On Sun, Mar 21, 2010 at 8:24 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 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 agree that the differences are really minor between those styles,
and I also agree with your reasoning as to why it is more consistent
with other existing Java constructs.

By the way, "mine" syntax is really yours :)  - I do not think that me
renaming "java.lang.Lambda" to "java.lang.Function" constitutes any
real contribution.

>I chose to use #
> for two reasons:
>
> It was used in the strawman
> It reminds people that this is not a normal class and that they can't write
> one of these themselves

My sole objection to # - which, actually, stretches out to other
proposals that use magic symbols, as well - is that it is "unnaturally
looking" in context of Java as it currently stands. It breaks the
long-standing assumption that type references always begin with an
alphanumeric identifier or keyword, and never with a special character
("int", "java.lang.String[]", "List<Object>" etc) So far the only
characters used in type references are: <>[].,?& - and they all come
after/between identifiers, not before them.

Of course, it's not something that was deliberately designed into the
language, but nonetheless, it does contribute to its existing look and
feel. I suspect (just a wild guess, of course) that it was a
subconscious factor in Joshua's assessment of several proposals as
"non Java-like". I do actually share that feeling - personally, when I
see something like:

  #<...> x;

or:

  #(...) x;

it just doesn't "click" for me as a variable declaration, because the
leftmost production simply doesn't look like a type "should" look in
Java.

Oh, and I would very much prefer a keyword ("lambda" or a different
one, doesn't matter) there over a "magic class name", but there's no
way to use one without breaking backwards compatibility, so far as I
can see. Even if using context keywords (a la C#'s "get" and "set"),
no reasonable syntax for function types that I've seen on this mailing
list so far would allow for a context keyword that is entirely
unambiguous.


Of course, this all is very subjective. I think, however, that there
is a real issue there, in that you can't just come with any random
syntax - no matter how logical, or convenient to parse - and have
developers like it and use it readily. To some extent, it also has to
be familiar. If it's a new concept, this means reinterpreting as much
of it as possible in terms of concepts that are already there, and for
those parts which really are new, thinking of how the established
patterns can be logically extended to cover them.

I do not claim that the proposal above is the solution (or even a
solution) to this problem. But I think that this is something that
really should be seriously considered when evaluating proposals,
alongside readability, lack of syntactic ambiguity, and
self-consistency.