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