I don't recall too much more in the book about strictness, but it's a great read nonetheless. 

The one thing it could do a better job of covering is how types defined with data and newtype differ, and how to use strict fields in data types. It does give an explanation of how to implement NFData in terms of seq, but you can often get away with simply defining strict data types. Some of that is in here, but there isn't a lot of explanation: http://www.haskell.org/haskellwiki/Performance/Data_types

I honestly don't recall where I picked up all that, it might've just been from reading parts of the Haskell Report or RWH.
https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2
http://book.realworldhaskell.org/read/profiling-and-optimization.html

I would recommend trying to understand the general case, not to look for specific examples of what not to do because you'll never find them all :) Ultimately it all boils down to following the pattern matching of constructors (since that's what forces evaluation to happen) and you should assume that Haskell is going to be as lazy as it possibly can (ignore what the optimizer *might* do). The special cases are seq, newtype, and strict fields.


On Mon, Jun 9, 2014 at 10:32 PM, Dimitri DeFigueiredo <defigueiredo@ucdavis.edu> wrote:
Thanks Bob.

Following your previous comment on this list, I read chapter 2 and really liked it, but I feel it was only scratching the surface. The example bug of implementing 'sum' using 'foldl' was insightful, but I'm sure 'foldl (+)' is not the only circumstance where laziness builds up large data structures unnecessarily and I'm afraid of recursion now.
Are there more insights peppered throughout the book? Or other good pointers you know?

Thanks again!

Dimitri


Em 09/06/14 23:21, Bob Ippolito escreveu:
I found the beginning of Parallel and Concurrent Programming in Haskell particularly enlightening:

After reading that, Haskell's evaluation strategy finally clicked for me. Now I can much more easily spot and fix these sorts of errors before even running them for the most part.


On Mon, Jun 9, 2014 at 10:01 PM, Dimitri DeFigueiredo <defigueiredo@ucdavis.edu> wrote:
Are there any good tutorials on understanding space complexity for haskell programs?

My current approach of "waiting for it to crash" by being out of memory, doesn't really seem like good engineering practice. However, I have not found a source that gives me any proactive insight into what should be avoided. Most of what I have read only helps to solve the problem "after the fact". How do we design programs that avoid those problems from the beginning? Any pointers?

Thanks,

Dimitri
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners



_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners


_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners