Overlapping data families don't make sense

overlap.hs

{-# 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

But is it really possible to write baz that way? And are the associated data declarations even syntactically correct? I think you'd need to provide actual separate data constructors for them, like data Bar () = UnitBar Void and data Bar a = OtherBar a. This would probably rule out the definition of baz, because you don't really know the data constructor to use.

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

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.

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 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.

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 type¹ with concrete data constructors (and then it is as if the type family never existed).

---

¹ 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.