It’s no different than having to know the associativity of an operator. Does “a - b - c” mean “(a - b) - c” or “a - (b - c)”? The former, for no reason other than a long history of convention. Same goes for function application. And you could make the same argument about languages that require parentheses for function calls: what does “a(b)(c)” mean? “(a(b))(c)” or “a((b)(c))”?

What’s gained is that the syntax mirrors the semantics. If you have a function “f : int -> bool -> int”, then “f 5” has type “bool -> int” and “f 5 true” has type “int”. It’s not like in Forth where you can’t tell from the syntax how many arguments a function takes.

That said, I do think right-associative function application may be more intuitive—I like having it in Perl, for example.

But it’s not `a b c`. Rather it’s something like `verb noun noun`. Which is much less ambiguous.

In a language with currying semantics [(((a(b))(c))(d)] the only logical explicit syntax sugar would be LISP-like, so (v n n), (v (v2 n)). That’s imo way worse — you end up with lots of useless junk)))))))) in anything non-trivial.

It would be `(a(b))(c)`. Interestingly, you're already leaving out parens for brevity.

More work for humans used to something else.

At this point it's worth reminding that ML syntax was originally designed to make programs more palatable to maths students...