Automatically derived instances
(BCC'ing the GHC bugs list) It seems like there's something very funky going on with GHC (6.4) and automatically deriving instances. Consider this code: ---8<-------------------------------------- 1: class MyClass a 2: 3:instance MyClass a => Show a 4: 5:newtype Type1 = Type1 { unType1 :: Int } deriving (Show) 6: 7:main = putStrLn $ show $ Type1 4 ---8<-------------------------------------- If you try to compile this, you get: ---8<-------------------------------------- Overlapping instances for Show Int arising from the 'deriving' clause of a data type declaration at Test.hs:5:8 Matching instances: Test.hs:3:0: instance (MyClass a) => Show a Imported from GHC.Show: instance Show Int When deriving the `Show' instance for type `Type1' ---8<-------------------------------------- Weird error. I haven't even declared an instance of MyClass! If I change line 5 to "deriving (MyClass), I get: *** Exception: stack overflow Sounds like a compiler bug to me. If I comment out line 3 and leave "deriving (Show)", it all works as expected. So... what's exactly the purpose of omitting the where-part of an instance declaration? It is supported, and it is even shown in code in the Haskell 98 report, but I failed to find any place in the whole document where it was described. Same thing for GHC's documentation. My purpose here was to do group classes for deriving like so: ---8<-------------------------------------- class MyNum a instance MyNum a => Eq a instance MyNum a => Ord a instance MyNum a => Show a instance MyNum a => Enum a instance MyNum a => Num a instance MyNum a => Real a instance MyNum a => Integral a instance MyNum a => Bits a instance MyNum a => Storable a -- Too long?... newtype ID = ID { unID :: WORD } deriving (Eq, Ord, Show, Enum, Num, Real, Integral, Bits, Storable) newtype ID = ID { unID :: Int } deriving (MyNum) ---8<-------------------------------------- I guess that's not doable? JCAB
Juan Carlos Arevalo Baeza writes:
(BCC'ing the GHC bugs list)
It seems like there's something very funky going on with GHC (6.4) and automatically deriving instances. Consider this code:
---8<-------------------------------------- 1: class MyClass a 2: 3:instance MyClass a => Show a 4: 5:newtype Type1 = Type1 { unType1 :: Int } deriving (Show) 6: 7:main = putStrLn $ show $ Type1 4 ---8<--------------------------------------
Your problem is the instance in line 3. The way Haskell type classes
work, the overlap is determined without looking at the context, so "Show
a" will overlap with every possible instance for Show, including Show
Int, which is predefined.
I'm not sure what the official justification for that is, but reason is
to avoid situations like this:
class A t where a :: t
class B t where b :: t
class C t where c :: t
instance A t => C t where c = a
instance B t => C t where c = b
instance A Char where a = 'a'
instance B Char where b = 'b'
What should c :: Char evaluate to?
--
David Menendez
David Menendez wrote:
Juan Carlos Arevalo Baeza writes:
The way Haskell type classes work, the overlap is determined without looking at the context, so "Show a" will overlap with every possible instance for Show, including Show Int, which is predefined.
Ah. :-P Bummer.
I'm not sure what the official justification for that is, but reason is to avoid situations like this:
class A t where a :: t class B t where b :: t class C t where c :: t
instance A t => C t where c = a instance B t => C t where c = b
instance A Char where a = 'a' instance B Char where b = 'b'
What should c :: Char evaluate to?
Right. Ambiguity. But as long as there's no ambiguity, there's no reason to be this restrictive. Oh, well. JCAB
just try to compile it with ghc -fallow-overlapping-instances -Wall --make Main.hs or inseart sth. like this at the first line: {-# OPTIONS -fglasgow-exts -fffi -fallow-undecidable-instances -fallow-overlapping-instances #-} - marc Am Montag, 29. August 2005 05:25 schrieb Juan Carlos Arevalo Baeza:
David Menendez wrote:
Juan Carlos Arevalo Baeza writes:
The way Haskell type classes work, the overlap is determined without looking at the context, so "Show a" will overlap with every possible instance for Show, including Show Int, which is predefined.
Ah. :-P Bummer.
I'm not sure what the official justification for that is, but reason is to avoid situations like this:
class A t where a :: t class B t where b :: t class C t where c :: t
instance A t => C t where c = a instance B t => C t where c = b
instance A Char where a = 'a' instance B Char where b = 'b'
What should c :: Char evaluate to?
Right. Ambiguity. But as long as there's no ambiguity, there's no reason to be this restrictive. Oh, well.
JCAB
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (3)
-
David Menendez -
Juan Carlos Arevalo Baeza -
Marc A. Ziegert