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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > _______________________________________________ > Glasgow-haskell-bugs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
