Compiler problem or dumb mistake?
Sun, 3 Feb 2002 15:26:33 -0600 (CST)
> Message: 4
> Date: Sat, 2 Feb 2002 15:58:39 -0500 (EST)
> From: <firstname.lastname@example.org>
> To: email@example.com
> Subject: Compiler problem or dumb mistake?
> Here's the problematic snippet, using GHC 5.00.2:
> mapWidList :: [(Int,Int,Bool)] -> [WidNode] -> Int-> [WidNode]
> mapWidList showList
> widNodes seq
> --map (\x -> (checkWid showList x (widNodes!!x)))
> -- [0 .. ((length widNodes) -1)]
> | (length widNodes ) < seq + 1 = 
> | otherwise = (checkWid showList
> seq (widNodes!!seq) ):
> (mapWidList showList widNodes
> The commented lines are what I would really like, but trace indicated
> that the anonymous function is never invoked, so I wrote out explictly
> recursive code. However, while trace indicates that the both alternatives
> are appropriately repeatedly tested, checkWid is never invoked. I have
> modified checkWid to assure that laziness is not the problem (I suffed in
> code that prevents prediction of the result returned by checkWid), so
> something else is going on here. Anyone care to take a shot at this one?
> Thanks in advance.
> Murray Gross
If checkWid is never invoked, then possibly it is never forced to begin
with, which I think means the bug is elsewhere in your code (or
For instance i trace the execution of the construction of [(x+2),(x+1),x]
etc (assuming absolutly no optimizations take place). taking the length
of that list will not force the individual thunks representing the values
of the elements of that list, even though (+) is strict. (In (x:y) the
list constructor (:) is lazy on both arguments x and y.)
When you mention you you stuffed code to ensure the result returned by
checkWid isn't predictable you did make sure to use the pragma that says
NOT to inline checkWid?
btw, your original map function could possibly be better written as a
zipWith as in..
zipWith (\w s -> checkWid ShowList w s) widNodes [0..]
zipWith is mentioned in the Prelude and is a fairly widely used