On Monday 17 October 2005 15:57, Simon Peyton-Jones wrote: > | Wolfgang Jeltsch: > | what ist the problem with instance declarations like the following: > | > | instance C Int a => D Char [a] > | > | Why are such declarations only allowed with > | -fallow-undecidable-instances in > | GHC? How can they result in undecidability? > > This one can't. But it's hard to formulate a general rule. > -fallow-undecidable-instances simply says that you, the programmer, > take responsibility for termination. Without the flag, GHC uses a > simple but sometimes over-conservative rule
Hi, I've now been bitten by the same 'over-conservatism' of H98. In my case it's Non-type variables in constraint: Pretty (tree a) (Use -fallow-undecidable-instances to permit this) In the context: (Pretty a, Pretty (tree a)) This is the data type declaration: > data Node23 tree a > = N2 (tree a) a (tree a) > | N3 (tree a) a (tree a) a (tree a) and this is the instance, where the error is reported: > instance (Pretty a, Pretty (tree a)) => Pretty (Node23 tree a) where > ... The class Pretty is from Daan Leijen's pprint library. I think that the 'non-type variable' refered to above is the application (tree a) in the constraint (Pretty (tree a)), which is arguably "almost" a type variable. In this case I think it is even more obvious that it can't cause a loop, since the LHS clearly has a type constructor removed, right? I mention this mainly because my module is otherwise completely H98 and I thought it would be nice to keep it that way. I need the Pretty instance for debugging only, so it's not really a show-stopper. Still I wonder if somebody knows a work-around that doesn't need a language extension (some newtype trick, maybe?). Ben _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell