Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. tutorials on space complexity? (Dimitri DeFigueiredo)
2. Re: tutorials on space complexity? (Bob Ippolito)
3. Re: tutorials on space complexity? (Dimitri DeFigueiredo)
4. Re: tutorials on space complexity? (Bob Ippolito)
5. Re: tutorials on space complexity? (Kim-Ee Yeoh)
----------------------------------------------------------------------
Message: 1
Date: Mon, 09 Jun 2014 23:01:38 -0600
From: Dimitri DeFigueiredo <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: [Haskell-beginners] tutorials on space complexity?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
------------------------------
Message: 2
Date: Mon, 9 Jun 2014 22:21:58 -0700
From: Bob Ippolito <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] tutorials on space complexity?
Message-ID:
<CACwMPm_LsCGjvUzJeCqFSA8EG91ML9ZqWo=k8XRaR=ngjrj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <
[email protected]> 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
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140609/a7bba69e/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 09 Jun 2014 23:32:15 -0600
From: Dimitri DeFigueiredo <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] tutorials on space complexity?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
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
> <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> http://www.haskell.org/mailman/listinfo/beginners
>
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140609/7be8c3e9/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 9 Jun 2014 22:53:23 -0700
From: Bob Ippolito <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] tutorials on space complexity?
Message-ID:
<cacwmpm9t9jxzwyc9ja9dqcodykarhrrnnlbqhrw5x2oea++...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <
[email protected]> 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 <
> [email protected]> 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
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>
>
>
> _______________________________________________
> Beginners mailing
> [email protected]http://www.haskell.org/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> 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-0001.html>
------------------------------
Message: 5
Date: Tue, 10 Jun 2014 16:01:59 +0700
From: Kim-Ee Yeoh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] tutorials on space complexity?
Message-ID:
<capy+zdsnekbpzz3c6djrr_qc0krzeweehgsf++ob7qkspan...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Jun 10, 2014 at 12:01 PM, Dimitri DeFigueiredo <
[email protected]> wrote:
> My current approach of "waiting for it to crash" by being out of memory,
> doesn't really seem like good engineering practice
Have you tried the graphical profiling tools?
And looked up RWH's chapter on profiling and optimization?
Don's answer here is a widely cited resource:
http://stackoverflow.com/questions/3276240/tools-for-analyzing-performance-of-a-haskell-program
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140610/a09e3a2a/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 72, Issue 9
****************************************
