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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
