Claus Reinke wrote:
ps. i was somewhat shocked to read that SPJ wants FDs gone.
Why? Simon has good taste. :)
de gustibus non est disputandum ;)
FD have uses and problems and AT have uses and problems. starting anew with the latter doesn't fix the problems, it just changes their form.
Well, the choice between FD and AT (and maybe yet undiscovered alternatives) is entirely a matter of "convenience" as much as everything related to type inference is. The same goes for type classes or subtyping: all these can be translated to system F (or FC for FD and AT) so they don't add abstraction power at run-time. Their only but important purpose is to auto-infer code. FD are pretty much type-level programming in a kind of mini-prolog. Of course, AT are type-level programming as well, but functional in style, which is arguably more compelling for a functional base language. At least, I think that FD are somehow ugly.
in particular, many of the problems with FD are ambiguities in interpreting interactions with other popular features, such as overlap resolution. it took half a decade of practical experience to expose such issues for FD, and i don't see the fact that AT haven't reached that stage yet as any advantage.
Quite telling that it took half a decade to shed light on the semantics of the many FD variants, isn't it? :) I guess that AT will come with semantics included because it's otherwise unclear how to implement them. Implementing FD is simply easier as type inference already is a kind of mini-prolog. Of course, that doesn't simplify their semantics at all. In a sense, knowing AT is knowing how much functional in style type inference can be. Regards, apfelmus