-
-
Save harpocrates/8e9c5d693f312e39fff4c7ae1df09f41 to your computer and use it in GitHub Desktop.
{-# 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 |
This doesn't work, and that's the point. How does this mess with associated type families? I don't see the issue there... With a type family, you would get a type mismatch at oops = baz
: Bar a
would reduce to something different that Bar ()
.
Note that associated data
are just syntactic sugar for regular data family
declarations, so there is no need for a Foo
constraint.
Note that associated data are just syntactic sugar for regular data family declarations, so there is no need for a Foo constraint.
Ah, I wasn't aware of that!
Bar a
would reduce to something different thatBar ()
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.
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.
Oh yeah, I need the constructors there. Why would that rule out the definition of
baz
though? We ought to be able to useOtherBar
without problem.