Aw, the Rust people will be either happy or sad about this.

Both at once, I imagine. Compromises were struck, and I think they were quite reasonable.

Just for the sake of discussion, what is actually wrong with the syntax you just invented?

Here are a few possible complaints:

    1. It's way longer
    2. Naming the monad "Action" may be misleading depending 
       on choice of Monad
    3. It's tied syntactically to the syntax of the implementation
    4. The <>s are superfluous
    5. The argument names are superfluous (to the type)
    6. The explicit type quantification is superfluous and verbose

> It's way longer

Because of the much longer type names which have nothing to do with the syntax.

By just replacing all the type names by the original single-letter names, it goes from 107 to 72 characters, that's almost 50% increase in size (49%) due to longer type names, which incidentally is nearly double the increase in size between the Haskell signature and this new signature (57 -> 72, or 26%)

    def M2<A1, A2, R, M: Monad>(f: (A1, A2) => R, a: M<A1>, b: M<A2>): M<R>

Funnily enough, this expansion is relatively worse if applied to the Haskell signature (57 -> 87, +53%)

> Naming the monad "Action" may be misleading depending on choice of Monad

Nothing to do with syntax either.

> It's tied syntactically to the syntax of the implementation

?

> The argument names are superfluous (to the type)

That can trivially be removed when just displaying the function's type (`f`'s arguments are not explicitly named after all), likewise for the unnecessary type quantifications, so a type-view of this function (rather than a source view) could be:

    def M2<M: Monad>((A1, A2) => R, M<A1>, M<A2>) => M<R>

Oh look, it's now shorter than the original signature (though somewhat more noisy, I'll give you that)

Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison. And if you want to be true to the semantics, you might write something like this:

    def M2 ((A1 => A2 => R) => M<A1> => M<A2> => M<R>) where Monad<M>

At which point the Haskell syntax is shorter. However, concision is not the goal—it’s merely a proxy for clarity.

> Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison.

But the conventions are whatever we want for a resyntacting no?

> However, concision is not the goal

I was answering a comment putting concision forward as reasons to dislike the alternate syntax.

Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature.

Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't.

And by the definition being tied to the implementation I mean that it's not possible to write, e.g.

    foo :: Type1
    bar :: Type2

    foo = ...
    bar = ...

> Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature.

pekk asked what was wrong with the syntax.

> Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't.

I didn't change the syntax in any way.

> And by the definition being tied to the implementation I mean that it's not possible to write, e.g.

'k.

Is that actually used? Global type inference I could see, but that seems odder.

Fair enough. I conflated syntax with convention.

It is used quite frequently, actually, e.g. in describing type classes.