simonpj at microsoft.com
Fri Dec 3 11:39:44 EST 2004
It is strange that adding -fallow-incoherent-instances should *stop* it
This does not happen in the HEAD. I can see why it happens in 6.2
You are on very very very thin ice with this program. You have
instance Confuse a => Typeable a
f :: Typeable a => ...
f x = ....stuff that needs Typeable ....
At any time the compiler might use the instance decl to reduce the
The only thing *stopping* it doing so is the desire to preserve
coherence, which is why it does though before you add the flag. When
you add the flag -fallow-incoherent-instances, the compiler feels free
to reduce Typeable a to Confuse a... but then it finds that the type
signature for f only provides Typeable.
Sorry.. but if you have all of
then life is pretty wild.
| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
| bounces at haskell.org] On Behalf Of Christian Maeder
| Sent: 30 November 2004 11:48
| To: GHC Users Mailing List
| Subject: -fallow-incoherent-instances
| The attached module does not compile and yields the following error:
| Could not deduce (Confuse a) from the context (Typeable a)
| arising from use of `breakFn' at InCoherentInst.hs:17
| Probable fix:
| Add (Confuse a) to the type signature(s) for
| In the first argument of `GeneralBreakFn', namely `breakFn'
| In the definition of `addGeneralFallOut':
| addGeneralFallOut = let
| breakFn a = throwDyn
| in GeneralBreakFn breakFn
| The same source compiles ok without -fallow-incoherent-instances (or
| with -fno-allow-incoherent-instances).
| If, furthermore, the "confusing instance" is commented out, the source
| even compiles without extensions.
| I don't know if this is a bug, possibly related to the import of
| Typeable stuff. I don't need a fix. I only want to point out that
| globally switching on the option -fallow-incoherent-instances is
| to break existing code, currently (ghc 6.2.2).
| Cheers Christian
More information about the Glasgow-haskell-users