Am 13.02.2016 um 08:31 schrieb Christopher Allen:
This is not how people think about, talk about, or motivate typeclasses in my experience. I haven't run into anyone fool-hardy enough to suggest a global namespace of unique instances getting provided by the compiler is a vehicle for modularity-via-(abstraction|sealing|etc.) YMMV
Well, make me the first one to do that ;-) Not for typeclasses. I suspect that namespaces and visibility should be managed independently of adaptation to the local needs, and I also suspect that both typeclasses and SML modules try to do both, making it hard to understand these aspects in isolation. The quoted paragraphs were a comparison. It seems that the SML folks are about namespace collisions of stuff from within a module. If that's a problem in Haskell, then that's an emarrassing weakness. If the SML folks think that's already "proper namespace management", they are mistaken (sorry folks), you need to deal with cases where module names themselves conflict. It's easy to underestimate the effect. For me, everything I code and vaguely expect to ever become public, I simply put into the org.durchholz namespace. That's my personal DNS name, so whenever I get around to actually publish something, at least I don't have to worry about having to rename uses lay_golden_eggs module because Goose Inc. already took that particular place in the global namespace. Even better, I don't have to worry about contacting everybody who uses my code to update it with the new name. [Please don't answer directly and CC to Haskell-Cafe, that's defeating my mailer's "reply-to-list" feature.]