How about a combo?

[Neal Gafter]

Howard's syntax combines the generics syntax (outside the angle brackets)
with a function type syntax (inside the angle brackets), thereby making the
syntax for a function type about twice as complicated as it needs to be.  He
invents the concept of varargs generics just for this purpose, when in fact
there is nothing varargs about disjunctive exception types.  To me, his
proposal looks like a mess of muddy thinking.  I didn't bother commenting
earlier because I didn't expect many people to take it seriously.

As for the part where you "borrow" my syntax, it isn't my proposed syntax at
all.  You've added an explicit result type and thrown exceptions, even
though every expression already has a type and set of thrown exceptions, and
you've added special and too-different forms for statement lambdas.  Not
quite as muddy as the function type syntax, but it doesn't really appear to
have an internal uniform consistency.  You've reintroduced an analogy with
method declarations that my syntax tries hard to avoid.

Cheers,
Neal

On Fri, Mar 19, 2010 at 9:26 PM, Pavel Minaev <int19h at gmail.com> wrote:

> On Fri, Mar 19, 2010 at 7:49 PM, Neal Gafter <neal at gafter.com> wrote:
> > On Fri, Mar 19, 2010 at 5:53 PM, Pavel Minaev <int19h at gmail.com> 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 (at
> 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?
>