<div dir="ltr">I don't recall too much more in the book about strictness, but it's a great read nonetheless. <div><br></div><div>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: <a href="http://www.haskell.org/haskellwiki/Performance/Data_types">http://www.haskell.org/haskellwiki/Performance/Data_types</a></div>
<div><br></div><div>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.</div><div><a href="https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2">https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2</a><br>
</div><div><a href="http://book.realworldhaskell.org/read/profiling-and-optimization.html">http://book.realworldhaskell.org/read/profiling-and-optimization.html</a><br></div><div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 9, 2014 at 10:32 PM, Dimitri DeFigueiredo <span dir="ltr"><<a href="mailto:defigueiredo@ucdavis.edu" target="_blank">defigueiredo@ucdavis.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Thanks Bob.<br>
<br>
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.<br>
Are there more insights peppered throughout the book? Or other good
pointers you know?<br>
<br>
Thanks again!<br>
<br>
Dimitri<br>
<br>
<br>
<div>Em 09/06/14 23:21, Bob Ippolito
escreveu:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">I found the beginning of Parallel and Concurrent
Programming in Haskell particularly enlightening:
<div><a href="http://chimera.labs.oreilly.com/books/1230000000929/ch02.html#sec_par-eval-whnf" target="_blank">http://chimera.labs.oreilly.com/books/1230000000929/ch02.html#sec_par-eval-whnf</a><br>
</div>
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Jun 9, 2014 at 10:01 PM,
Dimitri DeFigueiredo <span dir="ltr"><<a href="mailto:defigueiredo@ucdavis.edu" target="_blank">defigueiredo@ucdavis.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are there
any good tutorials on understanding space complexity for
haskell programs?<br>
<br>
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?<br>
<br>
Thanks,<br>
<br>
Dimitri<br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Beginners mailing list
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br></div>