On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe <o...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
