[Haskell-cafe] Possible Improvements

Johan Tibell johan.tibell at gmail.com
Mon Dec 3 03:43:16 EST 2007


> I agree that (in this context, beginning learning Haskell) it is a
> somewhat minor issue.  But I disagree that this is something you should
> ignore until it becomes a problem and I do think that it should be part
> of learning Haskell.  Properly using strictness is an important part of
> using Haskell.  It makes the difference between code that stack
> overflows and code that doesn't, code that takes 100 seconds and code
> that takes 10, code that uses 3MB of RAM and code that uses 600.  At
> least the first of these is not, in my mind, the difference between
> "optimized" and "unoptimized", but rather the difference between correct
> and incorrect.  Writing better code at the beginning is much easier than
> trying to figure out what the problem is later.  Furthermore, writing
> better code is not more difficult.  In this case it merely means adding
> two characters.  Of late, the "rules of thumb" for this sort of thing
> are becoming more widely known.  Such things need to be "instinctively"
> part of how you write code, much like writing code tail-recursively or
> not using (++) left associatively.  It's not that you should immediately
> know that this is better, but (more strongly) that you should not even
> think of the worse ways to begin with in many cases.

It would be great if someone could exemplify these "rules of thumb",
e.g. "Primitive types such as Int should be strict unless in the three
canonical examples X, Y and Z." My strictness radar is still quite
poor and I feel I can't make informed decisions on when I need to make
something more strict or lazy.

-- Johan


More information about the Libraries mailing list