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

[Alexander Dunlap]

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"?
>
> 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.
>
>>  From these programs
>> we can do a sampling.  While I'm not a statistics expert, my
>> understanding is the main problem with using hackage packages is a bit
>> of selection bias.
>
> I can see no reason to assume that it's only "a bit".
> Maybe it's a bit.  Maybe it's a very great deal.
> It would be interesting to investigate this, but the only way
> you can investigate it is to examine a lot of code that
> _isn't_ there.
>
>>  I bet the selection bias isn't even that bad for
>> this statistical test due to the nature of programming style
>> diversity.  Maybe someone with a stronger stats background could
>> comment.
>
> 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.
>
>> I think that would give us an exhaustive collection of haskell code,
>> but I assert we don't need that.  Biologists don't need a DNA sample
>> from every organism to draw conclusions about the genetics of a
>> species.
>
> 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.
>
>>  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.
>
> 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.
>
> 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.
>
>> That's the challenge I was trying to make in my first email.
>
> It's a challenge to the irrelevant.
>
> Let's consider three versions of naive Fibonacci.
>
> fibA :: (Integral a, Integral b) => a -> b
>
> fibA 0 = 1
> fibA 1 = 1
> fibA (n+2) = fibA (n+1) + fibA n
>
> Simple, readable, Haskell 98.
>
> pred2 :: (Integral a) => a -> Maybe a
> pred2 n = if n >= 2 then Just (n-2) else Nothing
>
> fibB :: (Integral a, Integral b) => a -> b
>
> fibB 0 = 1
> fibB 1 = 1
> fibB x | Just n <- pred2 x = fibB (n+1) + fibB n
>
> Uses a pattern guard, implemented in GHC.
>
> Pattern guards are neat.  I like them a lot.  They make sense.
> But it's impossible for me to see fibB as more readable than
> fibA.
>
> While pattern guards come _close_ to offering a replacement
> for n+k patterns, they don't quite.  If I had
>
> f x (n+1)
>  | p x = ...
>  | q x = ...
>
> I would have to write the pattern guard twice as
>
> f x n'
>  | Just n <- pred1 n', p x = ...
>  | Just n <- pred1 n', q x = ...
>
> That doesn't seem like an advantage, somehow.
>
> Now for the third alternative.
> The view proposal in the Haskell' wiki and the views implemented
> in GHC are different.  In fact the view proposal document goes to
> some trouble to show how views can replace n+k patterns, so I
> suppose I don't need to review that.  Here's what it looks like
> using GHC syntax.  (I can't make ghc 6.8.3 accept this;
> ghc --supported-languages does not list ViewPatterns.  So this is
> UNTESTED CODE!)
>
> data Integral a => Nat2 a = Succ2 a | One2 | Zero2
>
> nat2 :: Integral a => a -> Nat2 a
>
> nat2 n | n >= 2 = Succ2 (n-2)
> nat2 1          = One2
> nat2 0          = Zero2
> nat2 _          = error "nat2: not a natural number"
>
> fibC (nat2 -> Zero2)   = 1
> fibC (nat2 -> One2)    = 1
> fibC (nat2 -> Succ2 n) = fibC (n+1) + fibC n
>
> I like views a lot.  The GHC version of views seems particularly
> tidy.  But again, does anyone really think this makes the code
> *more* readable?
>
> I suppose I should include the 4th version:
>
> fibD :: (Integral a, Integral b) => a -> b
>
> fibD 0 = 1
> fibD 1 = 1
> fibD n = if n >= 2 then fibD (n-1) + fibD (n-2)
>         else error "fibD: not a natural number"
>
> That doesn't look like an improvement in readability or
> maintainability or any other illity to me.
>

fibE :: (Integral a, Integral b) => a -> b
fibE n | n < 0 = error "fibE: not a natural number"
fibE 0 = 1
fibE 1 = 1
fibE n = fibE (n-1) + fibE (n-2)

I personally find this a bit easier to read than the n+k one because
to think about this, I can just read the formula for the nth fibonacci
number. To read the n+k one, I have to look at the pattern, figure out
what n is (because it's not the argument to the function), and then
look at how the fib function is called. Notice that the n that is
passed to the next iterations of fibA does *not* have the same meaning
as the n within fibA.

Of course, readability is a bit subjective, but that's my point of
view. My main point here was to show that you don't need view patterns
or pattern guards to implement fib without n+k patterns.

Alex