[Haskell-cafe] Possible Improvements

[PR Stanley]

That's a very good point. Yes, let's have some detailed explanations 
accompanied by some good examples.
Cheers, Paul
At 08:43 03/12/2007, you wrote:
> > 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
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://www.haskell.org/mailman/listinfo/haskell-cafe