Warp wrote:

>   Which raises an interesting question: Can lazy evaluation hide bugs
> which could otherwise be immediately detected?

That *is* an interesting question.

Suppose you write a tokeniser that takes a string and returns a list of 
tokens. Suppose your program just counts how many tokens there are. You 
run your program, and it seems to work. Great!

Then later you change it so it tries to print out the tokens. And *now* 
you discover that processing the 8th token in the list causes a 
divide-by-zero error. Oops! If it weren't for lazy evaluation, you would 
have found that out sooner.

OTOH, by the simple act of printing out the token list while you're 
testing your tokeniser, you would probably have found that bug anyway. 
So it's a pretty contrived example.

Let us not forget, of course, that in a "normal" language it's not in 
any way unusual for changing the structure of a program to cause some 
new, previously unused code path to suddenly get used and reveal a bug 
or two that you didn't know about. So lazy evaluation doesn't make 
things *so* much different. It just makes it somewhat easier for certain 
kinds of bugs to hide.

(Of course, Haskell also makes it easier to test your functions. You 
don't have to write a whole test program, just open up GHCi and type in 
some expressions to check you get the right answers. And since printing 
out a value usually causes it to be completely evaluated, laziness 
shouldn't be hiding anything from you...)

Post a reply to this message