GADTs and functional dependencies

[Claus Reinke]

> This has never worked with fundeps, because it involves a *local* type equality (one that holds in 
> some places and not others) and my implementation of fundeps is fundamentally based on *global* 
> equality.  Prior to GADTs that was fine!

Thanks for the explanation, Simon - it clears up some outstanding FD issues.

> Now everything should be good.  Almost all fundep programs can be translated in this way.  (Maybe 
> all, I'm not 100% certain.)   If you are doing this yourself, you can usually remove C's second 
> parameter; but only if the fundep is unidirectional.

You can be 100% certain that not all FD programs can be translated to TF,
if only because of interaction with overlapping instances. This is an area where
Ghc differs from Hugs, doing different things for the "same" LANGUAGE
extension, and it is difficult territory: Hugs' interpretation is safe, but too
restricted in practice, Ghc's is a lot more flexible in practice, at the expense
of not knowing whether it is safe in general, leaving those concerns to type
class library implementers. I had hoped that Haskell' or Ghc would single out
the actual use cases, and work towards principled solutions for these, whether
for FD or for TF (eg, guards and closed instances might help).

> So, as of now (6.10), the fundep stuff is still handled exactly as before, using global 
> unification, so your program isn't going to work in 6.10 either.  I'm frankly dubious about 
> whether it's worth the effort of automatically performing the above translation from fundeps to 
> type equalities; if you want this level of sophistication, you could just use type functions 
> directly.
>
> It's not really a lack of backward compat.  I think 6.10 will do all that 6.8 does; but if you 
> want *more* you'll have to switch notation.  Does that help clear things up, and explain why 
> things are the way they are?

Many of the issues that are going to be fixed for TF have been raised as bugs
in the old implementation of FD. If FD are not going to see the same fixes, programs
need to switch to TF, which isn't backwards or otherwise compatible (and may well
deliver the final blow to the idea of more than one Haskell implementation?).

Claus