instance visibility (was: Re: The base library and GHC 6.10)

[Jonathan Cast]

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