Is it time to start deprecating FunDeps?

[AntC]

> <oleg at ...> writes:
> 
> I think this mechanical way is not complete.

Thanks Oleg for the counter-examples. I find them both rather mischievous, 
because they both go beyond the limits of what FunDeps can do:

In your class Sum example,
> 
>         class Sum x y z | x y -> z, x z -> y
> 
 your own solution has a bunch of helper classes (each with one-
directional FunDeps). Your solution has a single instance declared for the 
Sum class, with three bare typevars. So it is valid by step 1. of the 
rules I gave. (In your solution all the 'hard work' is done by the 
helpers, which are constraints on that single instance.)

(But I do concede that in general the translation rules I gave do not work 
for cyclic dependencies. I'm looking into whether I can beef up the rules 
to at least validate against a FunDeps class for instances that use EqC's.)


In your overlap example you introduce a definition that won't compile!
> 
> {- -- correctly prohibited!
> instance x ~ Bool => C1 [Char]  x where
>     foo = const True
> -}
You expect too much if you think a mechanical translation will 'magic' a 
non-compiling program into something that will compile.

I do expect equality constraints to not play well with overlaps. Combining 
FunDeps with overlaps is also hazardous. I'm only claiming that EC's will 
be at least as good.

In the HDeleteMany example I gave in the OP, yes the translation did solve 
a problem that blocked compiling. (And the HList paper also gives a 
solution using FunDep's which needs helper classes.) I'm not claiming that 
will always work. I'm not claiming that equality constraints are uniformly 
better than FunDeps; I'm only claiming that they're at least equivalent in 
power, and sometimes give easier to understand code.


And I find FunDeps not very, err, functional.