On Thursday 03 March 2011 17:40:52, Britt Anderson wrote:
This does fix the problem. Thank you. But raises a new question. Since that list was being constructed like this
where trialList oldps = [[(h' i) , (p' i)] | i <- [1 ..], i < tn]
where trialList oldps = [[h' i, p' i] | i <- takeWhile (< tn) [1 .. ]] The probem is that the compiler can't know that i never gets smaller than tn again once the first i >= tn is reached¹, so it is busy generating ever larger integers and testing them against tn, never finishing (well, it will finish when i is large enough to blow your memory, perhaps when i >= 2^(2^31) on a 32-bit system, I don't know how overflow of Integer is handled) ¹ An instance of Enum and Ord may wrap around, although that would be against the spirit of those two classes.
it should have only had two elements when tn = 3. So, I assume that I am getting hit by a laziness issue, but how is it that I should have known that using mapM_ wouldn't have force thelist to exist in a finite form?
Laziness only in so far as it's necessary for [1 .. ]. The issue has nothing to do with monads or mapM_, it's the fact that the compiler doesn't use 'rules that should hold for instances of ...' and hence has to try on after a human knows it's over.
By the way, I just now use "take (tn -1)" and all is good, but I would like to understand this issue better so I can avoid similar pitfalls in the future.
A similar pit is often fallen into with filter.
Thx, Britt