Skip to content

Instantly share code, notes, and snippets.

@harpocrates
Last active September 14, 2017 22:17
Show Gist options
  • Save harpocrates/8e9c5d693f312e39fff4c7ae1df09f41 to your computer and use it in GitHub Desktop.
Save harpocrates/8e9c5d693f312e39fff4c7ae1df09f41 to your computer and use it in GitHub Desktop.
Overlapping data families don't make sense
{-# 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
@sgraf812
Copy link

sgraf812 commented Sep 14, 2017

If anything, this would disallow overlapping associated type families. But I still doubt that you can just write baz that way, you'd at least need baz :: Foo a => a -> Bar a.

Well, at this point you could probably use baz x = OtherBar x even in the data family case... But I'm not really sure this works.

Edit: Actually, you don't need that context oO I'll have to think about this

@harpocrates
Copy link
Author

Oh yeah, I need the constructors there. Why would that rule out the definition of baz though? We ought to be able to use OtherBar without problem.

@harpocrates
Copy link
Author

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.

@sgraf812
Copy link

sgraf812 commented Sep 14, 2017

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 that Bar ()

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.

@harpocrates
Copy link
Author

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