RE: too liberal handling of instance imports?

Oops, I just found it.  It's in the user's guide, in the "Bugs in GHCi"
section:

http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-g
hci

Cheers,
        Simon

On 10 November 2005 10:39, Simon Marlow wrote:

> Indeed, it is a known bug (I thought it was in SF too, but I can't
> find it either).
> 
> The problem is a bit more restricted than just "GHC doesn't respect
> the importing structure when importing instances".  In particular, it
> works properly if any of the following are true (I believe):
> 
>   - you are not using --make or GHCi
>   - the instances are not in any external packages
> 
> in other words, GHC keeps a single bag of instances that it lazily
> slurps from external packages when compiling with --make or GHCi.
> 
> Cheers,
>       Simon
> 
> On 09 November 2005 23:49, Claus Reinke wrote:
> 
>> I was pretty sure this is a well-known and long-standing bug, but I
>> can't find it in the sf bug tracker, and the user guide "Known bugs"
>> section claims in 12.1.1.5 "None known", so I thought I'd ask here.
>> 
>> The problem, as I recall it, is that ghc's import chasing collects
>> instances as it follows dependencies, without respecting the
>> actual import relationships between modules. For instance, the
>> following compiles, but shouldn't (in my understanding, at least:-):
>> 
>> ---------------------------------------------
>> module A where
>> 
>> f = print ((Left "hi" >>= Right) :: Either String String)
>> ---------------------------------------------
>> module B where
>> 
>> import Control.Monad.Error()
>> ---------------------------------------------
>> module Main where
>> 
>> import B
>> import A
>> 
>> main = f
>> ---------------------------------------------
>> 
>> Could someone please confirm that this is a bug, not a mis-
>> understanding? Switching the order of imports in Main should
>> not have an impact on program correctness, but it does (win xp,
>> ghci 6.4.1; missing instance (Monad (Either String))). Similarly,
>> after a failed load (with flipped imports) in ghci, a simple
>> 
>>> m +Control.Monad.Error
>>> m -Control.Monad.Error
>>> r
>> 
>> should not succeed, but it does.
>> 
>> In a larger program (think of A and B as independent sub-projects,
>> from different vendors..), this is even harder to track (btw, can one
>> infer the compilation order from ghc -M output? I was at a loss
>> trying to find out why a certain module A was compiled at the time
>> it was, for one order of imports, but not for another - when the
>> compilation of A fails, the modules that caused A to be compiled
>> have yet to appear in the output.. ).
>> 
>> Cheers,
>> Claus
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-bugs mailing list
>> Glasgow-haskell-bugs@xxxxxxxxxxx
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
> 
> _______________________________________________
> Glasgow-haskell-bugs mailing list
> Glasgow-haskell-bugs@xxxxxxxxxxx
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs