Why do mainstream OOP languages have it so easy, while Haskell hasn't been able to solve the name collision problem for many, many years? Because mainstream object-oriented programming languages do not do (bidirectional) type inference, and the one exception I can think of (Ada) does not have variables in its type language.
Then isn't it a trade-off? Convenience of bidirectional type inference vs. convenience of name collision resolution? And Haskell type system seems to support making this trade-off on case by case basis. OverloadedLabels and my Insert example implement the exact behaviour provided by mainstream OOP languages (looking up the function by the type of the main argument and the name of the function). Are there some hidden pitfalls that I am not aware of? If not or if they aren't particularly devastating, then what's left is to make making the trade-off in favor of avoiding name collisions as convenient as in OOP languages.
Note: the "object" argument is second, not first. Currying and argument order really don't seem to be related. Haskell type-classes don't depend on which argument is which, after all. Consider class Addable f where Eq t => add :: t -> f t -> f t
Yes, but as far as I know classes still depend on the predictability of argument positions. The problem is that "the last argument of a function" is not easily (if at all, somebody please enlighten me) expressible.
And the OOP languages struggle to do what Haskell does easily.
Yes, but the lack of something this obvious, present in most languages and extremely convenient definitely has the potential to plant doubts in the minds of Haskell beginners, thoughts that can make them give up Haskell without giving it a fair chance: "Haskell is impractical, just as the rumours say. Oh well..." "Haskell development is too hindered by fear of making decisions. Long- standing problems will never get solved. Sigh... Back to Microsoft C# we go..."