Last active
September 14, 2017 22:17
-
-
Save harpocrates/8e9c5d693f312e39fff4c7ae1df09f41 to your computer and use it in GitHub Desktop.
Overlapping data families don't make sense
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{-# LANGUAGE TypeFamilies #-} | |
import Data.Void | |
class Foo k where | |
data Bar k | |
instance {-# OVERLAPPING #-} Foo () where | |
data Bar () = UnitBar Void | |
instance {-# OVERLAPPABLE #-} Foo a where | |
data Bar a = OtherBar a | |
baz :: a -> Bar a | |
baz x = OtherBar x | |
-- This is nonsensical! `oops` should not be able to have a non-diverging defintion, it has type `() -> Void`. | |
oops :: () -> Bar () | |
oops = baz |
Bar a would reduce to something different that Bar ()
Right, that makes sense. But isn't this also trivially the case for the data family?
Data families don't reduce - they are already reduced. And that is precisely why they can't overlap! GHC has no way then of knowing which of the overlapping data constructors you are talking about. With type families, since they are reduced at the type level, GHC eventually ends up at a concrete type1 with concrete data constructors (and then it is as if the type family never existed).
1 Sort of... Sigh. Because type families don't have to be total, they can end up stuck. This excellent blog post by Richard Eisenberg goes into more detail.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ah, I wasn't aware of that!
Right, that makes sense. But isn't this also trivially the case for the data family? Even more so than with type families, where we can 'reduce' the application, overlaps are sure to conflict in the case of data families.
I agree now with the hypothesis that overlaps don't play well with * families, though.