On Wed, 2008-09-24 at 18:48 +0100, Claus Reinke wrote:
http://www.haskell.org/pipermail/libraries/2008-September/010623.html .. What one cannot do (in Haskell 98) is to have two instances of the same class, for the same types, in the same import hierarchy.
Of course, when you consider that Main, by definition, imports every module in the program directly or indirectly, this is pretty close to saying `instances are global'. Isn't it?
Close, but no cigar!-) The global view accepts strictly more programs than the Haskell 98 view (see the mesage I linked to for an example).
Right. I (of course) take the global view as axiomatic, and I view Haskell 98's implementation something like this: If an instance is defined (somewhere in existence), then it should be in scope everywhere. This is indistinguishable, in practice, from being in scope everywhere the class and type are both in scope. However, implementing this would require the implementation to search *every* module with an orphan instance when looking for instances. (Conceptually, this should include all of Hackage; if you use an instance from a package, but nothing else, under --make (or -e or -i) that package should (in principle) still be found and linked in.) Presumably, it's easier to only search the modules you've imported for instances. So a compromise is adopted: modules imported (directly or indirectly) have to be searched, but other modules can safely be ignored. So I view refusing to import one module so you can define/import a conflicting instance as deliberate exploitation of a mis-feature/limitation of the language.
It would also refuse some programs that Ghc (in non-Haskell 98 mode) accepts. And would stand in the way of looking for more precise instance import/export control (see both of my messages;-).
Intentionally. I see type class systems where the dictionary type is not intended to be a singleton as a substantively different language feature than what Haskell type classes are intended to be. Both are useful, IMHO; at least, adopting named instances (or what have you) should be viewed as removing one feature from the language and adding another. It's not just an enhancement/strengthening of the language. jcc