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
