Haskell for the Evil Genius(yellosoft.us)
yellosoft.us
Haskell for the Evil Genius
http://www.yellosoft.us/evilgenius/
5 comments
Worse, I think it actually overwrites the fib he just defined with a function that simply pattern matches on 30 and returns 832040.
In GHCI, trying that example with fib 29 results in a non exhaustive pattern error.
In GHCI, trying that example with fib 29 results in a non exhaustive pattern error.
Exactly; just like
let 2+2=5 in 2+2
Yes, that line doesn't redefine the expression 2+2 as the author suggests; rather, it redefines the operator + as a function which only works on 2 and 2, and returns 5 for those arguments. e.g.
Prelude> let 2+2=5 in 2+3
*** Exception: <interactive>:1:5-9: Non-exhaustive patterns in function +And, considering syntactic sugar for operators, fib and (+) examples are quite alike
Prelude> let (+) 2 2 = 5; 4 + 2 = 42 in [2 + 2, (+) 4 2, 0 + 3]
[5,42,*** Exception: <interactive>:1:5-29: Non-exhaustive patterns in function +
Prelude> let fib 0 = 1 in fib 0
1Cute but the claimed example of memoization is just plain old recursion. Its a nicely styled tutorial with good flow that could perhaps use some time getting fact checked by the nice folks on the Haskell mailIng list
This seems very much a work in progress despite the apparent degree of polish. I wonder if the author asked for feedback in #haskell and someone decided to run around posting it here and there without reading it carefully? That happens a lot with Haskell...
I found the post interesting, that's why I submitted HN. I can't be blamed for other people upvoting it.
I didn't notice the errors but having people at HN showing me what is wrong helped me learn more about Haskell. I hope that pointing those errors helps make the post more robust, too.
I didn't notice the errors but having people at HN showing me what is wrong helped me learn more about Haskell. I hope that pointing those errors helps make the post more robust, too.
For the use made out for records there was no reason to derive Eq, Ord and Show.
Out of curiosity, is there a particular downside to deriving them if the type permits it?
I'd imagine you're unnecessarily polluting the type with unused functionality, no?
(not sure if this is true, perhaps GHC is smart about it).
If nothing else, superfluous derives would seem to distract/obfuscate your intent.
(not sure if this is true, perhaps GHC is smart about it).
If nothing else, superfluous derives would seem to distract/obfuscate your intent.
I recommend rotating the pitchfork to make it look like a lambda.
This is not what I would normally consider 'lazy' or 'memoization'...
Not to be too pedantic but that 'sieve' is also not really the sieve of Eratosthenes either, as it continually recomputes each slot:
http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf