[Haskell] really undecidable instances?
benjamin.franksen at bessy.de
Sun Oct 30 16:14:10 EST 2005
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
I've now been bitten by the same 'over-conservatism' of H98. In my case
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?).
More information about the Haskell