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,
Right.
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 http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveNPlusK 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, http://hackage.haskell.org/trac/haskell-prime/wiki/Status 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.