Re: Class System current status
Stephanie wrote:
Simon,
Why is an Appendix is better than just a footnote in the Standard that says "we aren't sure, one way or the other, whether FDs will stay in the language for ever." Why do we need this extra structure?
I'm worried that this extra structure could be confusing. In particular, if someone says "this program is pure Haskell'" what will that mean? In practice, will it be clear whether pure Haskell' includes the Appendix?
I don't like the appendix idea either--or a footnote for that matter. I don't think a language definition should be cluttered by remarks about whether or not the designers are sure they got each bit right. It should just define a language. It seems to me that Haskell' is gaining a status in our minds that it doesn't deserve--that the "main" language report should be a thing of permanence that will stand the test of time. Previous versions of Haskell haven't. There was no footnote in the Haskell 1.2 report indicating that the IO system might be replaced... yet that's exactly what happened in 1.3, a much more dramatic change than replacing FDs by ATs will be. Future versions of Haskell may change things--that's a given. The language will continue to evolve. We've even been discussing changing the semantics of pattern matching this time around--which shows that even basic parts of the language may be called into question in the future. 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. John
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.
participants (2)
-
John Hughes -
Manuel M T Chakravarty