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

Richard O'Keefe ok at cs.otago.ac.nz
Thu Apr 23 01:30:52 EDT 2009

On 23 Apr 2009, at 2:09 am, John A. De Goes wrote:

> That's absurd. You have no way to access private source code,


> so any decision on what features to exclude from future versions of  
> Haskell must necessarily look at publicly accessible source code.

Wrong.  There is no "necessarily" about it.  People made decisions
about what to deprecate in the Fortran and COBOL standards without
looking at publicly accessible source code.  The changes made in
producing ECMA Eiffel were _definitely_ done without looking at
publicly accessible source code.

And the decision to remove n+k patterns from Haskell', wrong though
I think it was, was NOT made on a nose-counting basis.  Or if it was,
there is not the slightest evidence of it in

The reasons for the removal are, in order
  - no other data type has it
    (and how many other data types allow [a,b,c] as well as a:b:c:[]?)
  - a somewhat bogus claim about how much of the library you need to
    know how to use it (of COURSE you need to know about integers in
    order to use an integer operation, what's so bad about that?)
  - the claim that + doesn't mean + (this is really an argument about
    the scope of + and could have been dealt with by ruling that n+k
    is only available when the version of + in scope is the one from
    the Prelude)
  - an assertion of personal taste (the side condition that the
    thing is FOR is called 'ugly')
  - a pious hope that something might replace them
  - another assertion of personal taste.

That's *it*.  There is nothing about the operation being *rare*
in any source code, publicly available or otherwise.  There is
no suggestion that commonly used features would not be proposed
for removal.  For example, "." as the composition operator, and
"~" lazy patterns, have both been proposed for removal.

> The only alternative is to continuously add, and never remove,  
> features from Haskell, even if no one (that we know) uses them.

Look again at the Haskell' status page,

Of all the proposed removals, n+k is the ONLY one to have been
accepted.  It may well be true that someone counted how many
publicly accessible modules use those features, but I cannot
find any evidence in the Haskell' wiki that this is so, or for
that matter that people would have cared very much.  (Meyer
wasn't bothered by the major incompatibilities between ETL3
Eiffel and ECMA Eiffel.)

With this one unique solitary exception, so far Haskell'
*is* just adding features to Haskell.  So if trawling through
publicly available sources is somehow supposed to stop that
happening, I'm sorry, but it hasn't done so yet.
> Moreover, the odds that everyone who is using n + k patterns are  
> doing so only in private is an untestable hypothesis (i.e.  
> unscientific) and extremely unlikely to be true.

It's also a straw man argument.  Nobody says that.
I certainly don't.  What I DO say is that
  - MY code contains n+k
  - MY code is not publicly available (there are many much brighter
    people than me working on Haskell and whenever I have a cool idea
    it has so far always been done, and in any case, much of the
    Haskell code I've written would be of no interest to anyone else)
  - so the nose counting process would certainly miss ME
  - there doesn't seem to be any reason to consider me unique
We simply DON'T KNOW how many people are using n+k patterns
or anything else that people have proposed for removal from Haskell'.
One thing we DO know is that existing Haskell textbooks teach the
use of n+k patterns.

Is there a simple way to download everything from Hackage?
As I've said before, trawling through stuff like that _can_ show
that something is used, but if it doesn't show that, we do NOT
learn that it isn't, but only that we DON'T KNOW.

As someone who is only a Haskell user, I don't really have any
*rights* in the matter.  Using Haskell at all is a privilege,
and if the Haskell committee decide, and Haskell implementors
agree, to remove a feature that I like, then I just have to
live with it.  But let's not pretend that this was ever about
how many people used the feature.

More information about the Haskell-Cafe mailing list