2 days ago Richard Eisenberg (and mniip) wrote:
... On incremental improvements / the "half-baked" nature of type families: I agree completely. ... ["half-baked" is Richard quoting mniip]
... the weird place of type families in the language. It is my hope that Dependent Haskell will obviate a lot of these concerns, allowing us to deprecate type families as we know them (you would just use an ordinary function in types instead).
From what I can make out, though, in Richard's Dissertation,
I don't want to sidetrack the github discussion on mniip's proposal. https://github.com/ghc-proposals/ghc-proposals/pull/52 So please explain here in what way type families are "half baked". The part of type families I find hard to use and hard to reason about is closed type families. I'd be very happy to deprecate them, if there was something that did overlaps better. they can't be promoted to "ordinary functions in types". If the closed equations were ordinary functions in types, you could go:
type family F a b type instance F Int b = b type instance F a Bool | a /~ Int = a -- non-unifiability guard
With no need for a closed sequence of choices. Is this the "case-like computations" others talk about on the proposal? AntC