On Sep 4, 2008, at 9:52 PM, Tim Chevalier wrote:
I'm no master, but I've never encountered a situation where strictness
annotations would be useful as documentation, nor can I imagine one.
I'm no master either, but how about these simple examples?
data Stream a = Cons !a (Stream a)
data Vector3 a = Vector3 !a !a !a
The compiler will certainly be able to infer the strictness itself in
most uses, so obviously the purpose for these annotations is not for
optimization, but I still would find these annotations useful. This is
much like explicitly giving the type for a function. It guides the
reader of the program, and just happens to also assist the compiler a
little bit.
That's because optimization *is* the only reason why programmers
should care about strictness information. IMO, arguing that
programmers should care at all amounts to conceding that default
laziness is treacherous.
If optimization is the only reason to worry about strictness, then
default laziness really _is_ treacherous. Luckily this is not the
case. Laziness is not useful without strictness, otherwise there would
never be any evaluation. Understanding how to apply laziness and
strictness in different situations is critical to writing efficient
but meaningful code in Haskell.
To quote a blog article[1] I wrote in June,
"It is simple and idiomatic to use strictness where your
program calls for it. In other words, contrary to many
complaints, strictness is not a low-level optimization
technique. Strictness is a strategy for algorithms. As is
always the case, if you change an algorithm, its time and
space requirements will change, but it’s a high-level
change. A strictness annotation or data structure redesign is
not like dropping to C or assembly."
The article explains laziness and strictness as I understand it. I
could be wrong, but my understanding seems to have served me well so
far.
- Jake McArthur_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
