
On 23 Apr 2009, at 2:24 am, Achim Schneider wrote:
"Richard O'Keefe" et all wrote:
[n+k patterns]
I'd like to add my two cents: Assuming that UHC's roadmap strives to be H'-compilant in the future, and n+k patterns aren't going to be in H', why bother implementing them?
Haskell' is a moving target. There are as yet no programs that are *known* to be Haskell' programs. There are as yet no Haskell' textbooks. (I remember someone once wrote a book about Prolog that presented Prolog according to the then-current draft of the standard. The next year the draft lurched back towards then-current practice, and the book was left describing a language that was never implemented.) If you want to support existing code written by people trained on the existing textbooks, you support as much of the existing language as you can. Otherwise you have to rely on people writing code specifically for your compiler.
Also, assuming that current H98 code will be ported to H', shouldn't n+k patterns be removed from existing code, anyway?
Someone who really believed that would surely be recommending that a compiler accept the feature and generate working code for it but WARN at each occurrence with a warning that can't be switched off. That would be a useful way to help people remove this clarity from their code. No, the UHC people can do what they please. It's _their_ compiler. It's _great_ that there's another almost-Haskell98 compiler. It's a little puzzling that section 3 "Language extensions and differences with Haskell98" says nothing whatsoever about n+k patterns. It's only in section 4.1, where we learn also that 'default' isn't there and might never be. We don't yet know whether 'default' will be in Haskell'. We also learn from http://www.cs.uu.nl/wiki/bin/view/Ehc/EhcUserDocumentation that IO is "under construction", Directory, Time, Locale, CPUTime, and Random are "not available". This is clearly work in progress, and we can only be thankful for something that's intended to be read as well as written. In fact, I've downloaded it, precisely in order to see how much work it will be to add n+k support. The thing is that it really seems bizarre to see this one feature singled out for non-implementation. If I can do the equivalent of n+k patterns by programming in the *type system*, why *not* in a pattern?