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