How about a combo?

[Jesse Kuhnert]

I'm sure I'll be corrected by someone then, assuming I'm wrong.

On Monday, March 22, 2010, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> I think Howard might be on to something, so make that one. Also, I don't think you have the qualifications to decide that what Howard posted was noise, but your half-baked defense of Neal's clearly argumentative "I don't understand anything" posts isn't.
>  --Reinier Zwitserloot
>
>
>
> On Mon, Mar 22, 2010 at 3:49 AM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:
>
> 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 > (athttp://Lambda Syntaxes <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?
>>
>>
>
>
>
>