Sure it differentiates it fine, the first token is the function, the rest are the arguments, that is not implementation leakage but rather just getting rid of superfluous things like commas that are just noise in ‘getting work done’, a lot of languages use this pattern of function calls, including ones without automatic currying.
Eh, not really, more I’d say it feels like it wraps the type system in most case, which is a bit of a mixture of sometimes conflicting ideas (hence why I prefer OCaml’s type system).
Interfaces/abstractions is something haskell does quite well (though not really in my preferred way). Classes/Objects from the traditional OOP world (not true OOP as it was originally defined, though smalltalk does this better than most) is useful in some cases, but it is also way WAY overused in places where it is just not suited, and that is when you start running into conceptual-hell (unable to follow the code flow because of how the poorly designed abstractions confuse which path code can take through the object calls) and the thousand-paper-cuts-of-death (OOP style abstractions are hell to optimize so you end up doing a lot of indirect function calls on the machine, which is death for performance-sensitive programs that overuse virtual calls).
Actually BEAM Behaviours are more like typed module interfaces. These worked really well with tuple calls that were removed just recently. It’s a great common OCaml idiom that is trivially optimizable but utterly fantastic at abstractions (unlike OOP abstractions).
