On Tue, Jan 31, 2012 at 9:19 PM, Steve Severance
The other thing is that deepseq is very important . IMHO this needs to be a first class language feature with all major libraries shipping with deepseq instances. There seems to have been some movement on this front but you can't do serious parallel development without it.
I completely agree on the first part, but deepseq is not a panacea either.
It's a big hammer and overuse can sometimes cause wasteful O(n) no-op
traversals of already-forced data structures. I also definitely wouldn't go
so far as to say that you can't do serious parallel development without it!
The only real solution to problems like these is a thorough understanding
of Haskell's evaluation order, and how and why call-by-need is different
than call-by-value. This is both a pedagogical problem and genuinely hard
-- even Haskell experts like the guys at GHC HQ sometimes spend a lot of
time chasing down space leaks. Haskell makes a trade-off here; reasoning
about denotational semantics is much easier than in most other languages
because of purity, but non-strict evaluation makes reasoning about
operational semantics a little bit harder.
In domains where you care a lot about operational semantics (like parallel
and concurrent programming, where it's absolutely critical), programmers
necessarily require a lot more experience and knowledge in order to be
effective in Haskell.
G
--
Gregory Collins