qualification of Data.Map (Was: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method)

[Henning Thielemann]

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.