[Haskell-beginners] tutorials on space complexity?

[Bob Ippolito]

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 at 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:
>
> http://chimera.labs.oreilly.com/books/1230000000929/ch02.html#sec_par-eval-whnf
>
>  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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>
>
>
> _______________________________________________
> Beginners mailing listBeginners at haskell.orghttp://www.haskell.org/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20140609/f3a288bb/attachment.html>