John Hughes:
Haskell' should define a standard language for use TODAY--and it should be 100% clear what that language is, with no pussy-footing around difficult choices. In my view it should include FDs. Then in the future they may be replaced--but it should then be clear that this IS a replacement, with no arguments of the sort "well it's not really an incompatible change because FDs were only in an appendix"! Let's face it, people ARE going to use FDs whatever the standard says, because they're just so godamn useful, and rewriting those programs if FDs are replaced by ATs is not going to be any easier because it's an appendix that's changing, rather than the main body of the report.
I agree that having FDs in the appendix does not make an essential difference to how easy they are to replace. Hence, I proposed a variation on this proposal is that we actually delay issuing the appendix. More precisely, * Specify MPTCs in the main language. * Finalise Haskell' without an FD/AT appendix. * Take our time to find out exactly how we want to do type level programming (with FDs, or ATs, or both). Once we know, we add an appendix on type-level programming. This moves the MPTC dilemma out of the critical path for Haskell' as a whole, but avoids that we have to rush the FD/AT issue. Manuel PS: I actually thought that this was what Simon proposed when he originally brought up the appendix idea, which may have been only between the class system subcommittee members.