Is it time to start deprecating FunDeps?
AntC
anthony_clayden at clear.net.nz
Wed May 1 02:40:06 CEST 2013
> Andres Löh <andres.loeh at ...> writes:
> ...
>
> I think the main "problem" of the type families vs. fundeps discussion
> is that they're two rather involved language extensions that in
> addition have very subtle differences.
Thanks Andres, but let me be clear: I am _not_ discussing Type Families
vs. FunDeps.
I'm talking about equality constraints only. Yes, equalities and Type
Families arrived (in GHC) at the same time, but they are different
features. (There were many creative ways to achieve something like
equality constraints long before the TF work. For example various
TypeCast's in the HList work. And really the compiler's type inference is
just equality constraint-solving. What arrived in GHC was making
equalities explicit in the surface language, and making sure it integrated
with type inference.)
There are some not-so-subtle differences between TF's and FunDeps.
Especially that FunDeps support overlaps (well, up to a point) -- so no
surprise that the counter-examples in Oleg's post concentrate on overlap
problems.
I am certainly not suggesting that equalities 'solve' those problems. I am
saying they're no worse than FunDeps. And that by taking away FunDeps we
simplify the choices around MPTC's in Haskell Prime.
> ... If, however, there's a correct and complete unification
> of the two concepts in terms of a common underlying formalism,
If by "the two concepts" you mean TF's and FunDeps, then: no, there is no
such unification. (There are many commonalities, but as you say,
subtle/frustrating differences.)
I am claiming FunDeps can be expressed as equality constraints. I'm also
of the opinion that FunDeps require a mental model that doesn't fit well
with a functional language. So I'm arguing for simplification.
More information about the Haskell-prime
mailing list