

Haskell for the Evil Genius - vimes656
http://www.yellosoft.us/evilgenius/

======
flatline

      main = let fib 30 = 832040 in do
    	putStrLn (show (fib 30))
    

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>

~~~
ricree
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.

~~~
ramchip
Exactly; just like

    
    
        let 2+2=5 in 2+2
    

amusingly returns 5.

~~~
samstokes
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 +

~~~
lelf
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
      1

------
carterschonwald
Cute 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

------
Hemospectrum
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...

~~~
vimes656
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.

------
mhitza
For the use made out for records there was no reason to derive Eq, Ord and
Show.

~~~
ricree
Out of curiosity, is there a particular downside to deriving them if the type
permits it?

~~~
rbxbx
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.

------
shasta
I recommend rotating the pitchfork to make it look like a lambda.

