How about a combo?

Sun Mar 21 23:48:36 PDT 2010

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
> 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?
> >
> >
>
>