def M2<T1, T2, Result, Action : Monad>(
      f: (T1, T2) => Result,
      a: Action<T1>,
      b: Action<T2>): Action<Result>
    {
      …
    }

This notation I’ve suggested doesn’t even accurately express such details as currying and typeclasses, which the original notation conveys neatly.

    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

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>

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

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

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.

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 = ...

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.

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

For the record, I can read both standard notation music and guitar tabs. I'm fairly competent at Haskell have written APL/J/K derivative languages for a living. "Mastering reading Haskell" certainly has to do with a lack of "go to this page on the wiki/hoogle/haddock and you can read the meaning and idiomatic usage of the 95% most common operators", not a lack of conceptual grasp of anything difficult.

It's in no way comparable to learning math notation or music notation.

Implementing exactly Haskell's rule for indentation is incredibly hard. In fact, no known Haskell compiler gets it right.

https://mail.haskell.org/pipermail/haskell-cafe/2009-April/0...

There's a few things, like fixity declarations, that make parsing Haskell not quite as easy as it could be.

Well, its an ML-derived syntax rather than the more common Algol-derived syntax, which forms something of a familiarity obstacle for programmers whose background is largely in Algol-derived syntaxes.

Its probably somewhat easier if you've learned another ML family language first -- especially given that idiomatic Haskell often involves wrapping your head around semantics that are unfamiliar as well, so that you aren't trying to take on both at once.

OTOH, I think the kind of ML-based syntax Haskell uses is a good fit, and its worth learning.

Your example of course is `do` notation which is tricky, and is really kind of advanced -- it's much better to use `>>=` `>>` and `return` as long as you can stand before breaking out `do`. If nothing else avoiding `do` will make you write smaller functions!

By "syntax" of course I mean "keywords". Haskell allows for infix operator creativity which you might see as a drawback. I would rather have a language be maximally expressive, allow me to define my own infix swear-word "operators", than be coddled and censored like almost every other language outside C++. But as for built-in syntax, there's hardly any. `$` and `.` are freaking library functions.

As for types, well, types are hard to read. Why shouldn't they be? It's not like templates are easy in C++ once you leave the most trivial exercises. At least Haskell's are formally consistent and fundamentally related to your definitions -- unlike templates which are really macro soup.

In any case, I would find your `M2` definition a lot easier to read with `a` and `b` instead of `a1` and `a2` ...

Now, I'm not at that level of proficiency, but I can tell that your example above takes a binary function and 'lifts' it into a higher (monadic) context, so that it can work on monadic values. And the reason I can work this out is because I know about the Functor typeclass which has the function fmap :: (a -> b) -> f a -> f b, which does a similar job of lifting an input function into a higher context (in this case a functor context).