Thanks a lot! This makes clear. I haven't noticed before that OverlappingInstances don't look at constraint!
John Lato-2 wrote > This line > > instance Monad m => Applicative m where > > tells the compiler "Every type (of the appropriate kind) is an instance of > Applicative. And it needs to have a Monad instance as well." > > That's what Edward means when he said that it means "every Applicative is > a > Monad". Theoretically the statement makes no sense, but that's what this > instance head means. Everything is Applicative, and it also needs a Monad > instance to use that Applicative. > > Consider what happens for something that isn't a Monad, e.g. ZipList. > Since it's not a Monad, it would need its own instance > > instance Applicative ZipList where > ... > > But now you'd need to enable OverlappingInstances, because ZipList matches > both this instance and the general one you've defined above (GHC doesn't > consider constraints when matching instance heads). OverlappingInstances > is much more problematic than the other extensions because it could (and > almost certainly would in this case) give rise to incoherence (see the > warning under > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap > ). >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Why-superclass-instances-are-bad-idea-tp5737056p5737139.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe