[Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) -- first release

[Richard O'Keefe]

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?