On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe
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