How about a combo?

[Jesse Kuhnert]

Could be he's the only one nice enough to give feedback when it's desired.

You'll notice the number of people responding positively to your
proposal that also have Lang design experience is currently 0 vs a lot
of well meaning I'm sure but probably not entirely realistic noise.

Discusiion is good but I worry that people like you are hogging up so
much time "discussing" things that can't possibly happen that we might
be missing out on the really good discussions from "informed opinions"
- which is what I vaguely remember the "come on down to the poject"
announcement mentioning.

Sorry if this sounds overtly negative, I'm sure you may be more
knowledgeable than me. I just want the best outcome possible.

On Sunday, March 21, 2010, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 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://Lambda Syntaxes <http://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?
>
>