Am 24.02.2014 22:37, schrieb Casey McCann:
The need for qualification with Data.Map (and the modules it would clash with) is a clear wart due to lacking appropriate type classes for collections. You probably shouldn't use that to support your point.
That's an interesting point. However, I don't believe that there is an elegant solution to e.g. unify Map.insert and Set.insert using an advanced type class. I often see people trying to resolve name conflicts by type classes, often indicated by FlexibleInstances. I think this in turn is abuse. It is certainly ok to use (<>) for different types via the Monoid class, but already this one is difficult, because for Maps there are different sensible implementations. That is, we won't get rid from names with module dependend types, we cannot and should not resolve every conflict using type classes. There are many cases where the module system is the better tool than advanced type hacks.