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

[Jason Dagit]

On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:
>
> On 21 Apr 2009, at 7:39 pm, Jason Dagit wrote:
>>
>> Not really.  Obviously some programs use the feature, but let us
>> restrict to interesting programs that have been shared with the world
>> and have some potential to receive maintenance.
>
> Why?
>
> You are, in effect, saying that my code has no value at all.
> You are saying that code written by students has no value at all.
> Why do you think that only code that is "shared with the world"
> has "some potential to receive maintenance"?

Code which is not used has what value exactly?  Other than some
learning value for the author, what is the purpose?  You also
misinterpreted my grammar.  That "and" is a logical one.  For example,
I intended to exclude programs which have been shared but have no
maintenance.

> By the way, not all publicly available code is in Hackage.
> The hbc release that's on my SPARC -- and thankful I've been for
> it, the grief GHC has given me there -- has at least one use of
> an n+k pattern that I know of, and more in a specification comment.

I know not all publicly available code is there.  I said as much in my
previous mail.  If a code base the size of hbc has one use of n+k
patterns, I bet you know enough that you could rewrite it to not need
it with very little effort, FWIW.

> I have a statistics degree.  I don't know if that's strong enough
> for you.  It's strong enough that I assume selection bias until I
> see evidence otherwise.

Then please, apply what you know and let's take the rumor, conjecture,
and speculation out of this discussion.

> It depends on what _kind_ of conclusion they want to draw.
> If they want to show that some feature _is_ present, a sample
> will do.  If they want to show that it's absent or rare, then
> they need a much bigger sample.

And Hackage is the largest sample I can think of.  Feel free to
provide a larger sample if you have one.

>>  Scientists work with incomplete data and draw sound
>> conclusions in spite of that.  The tools they use to do so are known
>> as statistics.
>
> Yes, I know.  That's why I get cross when people suggest silly
> things like trawling through Hackage to demonstrate that nobody
> is using n+k patterns.  Where's the statistics in that?  Where are
> the estimates of natural variation?
>
> Note: I do not assert that the use of n_k patterns is rare.
> Here's _all_ that I assert about n+k patterns:
> (1) they are part of Haskell 98
> (2) I believe they make programs more readable
> (3) I use them
> (4) they are no worse than certain features proposed for
>    addition to Haskell'.
>
>> Okay, then prove n+k patterns are not rare in the publicly available
>> sources.
>
>
> Why the X should I?  I do not claim that they are common
> IN THE PUBLICLY AVAILABLE SOURCES, I have NEVER claimed that,
> and I don't even CARE whether they are rare in the publicly
> available sources or not.

Please.  Let's remain calm.  This is just a thread on a geeky mailing
list for Haskell enthusiasts.  I'm not trying to raise your taxes,
take away any rights, or insult / offend you.

Why?  Because you're a stats expert so you have the necessary
background to do it right.  Also, because, hey, it would be
interesting to see the numbers.  Plus, it seemed relevant to me.

> Because they make programs more readable, n+k patterns
> probably *should* be moderately common in the publicly available
> sources, but I have no idea whether they are or not.

Personally, when a public debate stops being about provable things I
get bored.  Unless the next reply to this involves more facts and less
speculation I have no plans to reply.  Not to be rude, but the thread
would be a waste of my time at that point.

> It *is* true that things that *are* used in the commonly
> available sources should continue to be supported in order
> to preserve the value of those commonly available sources.
> It is *not* true that things that are *not* used in the
> commonly available sources are therefore of no value and
> safely to be discarded.

Ah, I think I see where we disagree.  Things which are:
1) rarely used;
2) add complexity to implementations;
3) add complexity for novices; and
4) are easily replaced;
should be removed from the specification so that it is simpler.  I
have a belief that n+k patterns fit the above 4 items and that taken
together they are sufficient, although perhaps not necessary or
complete in general, as a reason to move towards removing them.  I
thought it would be interesting to have someone make a measure of #1.
I think #3 applies here because it has to be explained.  As a
programmer, I didn't immediately grok it even though mathematically it
makes  sense.  I doubt any of the reasons taken individually would be
enough unless it is an extreme case.

I'll also mention that I don't think Fortran is great language just
because it takes on the burden of backwards compatibility.  I think
there should be a balance.

> Let's consider three versions of naive Fibonacci.
[snip]
> That doesn't look like an improvement in readability or
> maintainability or any other illity to me.

I think these examples show that fibs is easy to implement with or
without n+k patterns.  And we haven't even gotten to the trivially
memoized fibs yet.  I'm really fond of this one for example:
fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

Where you get the Nth fib (starting from 0) with fibs !! N.

Jason