Dear all,
My question is: how predictable is the ghc-0.29 laziness?
Has the implementation some bug about this ?
For look at the function
------------------------------------------------------------------
h js = Just (t js) :: Maybe [Int]
where
t [] = []
t (j:js) = let js' = map (g j) js in j:(t js')
g i j = mod (i+j) 5 :: Int
-- just to do something non-trivial with i,j
data Maybe a = Nothing | Just a
------------------------------------------------------------------
One can see by the algorithm that, say, for a list js = [1..1000]
the 8-th element of the result can be obtained many times faster
than the 800-th one. And the test confirms this:
------------------------------------------------------------------
main = let { n = 1000 :: Int; js = [1..n]; k = 8 :: Int }
in
case h js of Just xs -> print (show (xs!!k) )
_ -> error "error"
------------------------------------------------------------------
time for xs!!8 << time for xs!!800
But a slight complication of h to f spoils the effect:
------------------------------------------------------------------
f [] = Just [] :: Maybe [Int]
f (j:js) = case f (map (g j) js) of Just js' -> Just (j:js')
_ -> Nothing
------------------------------------------------------------------
time for xs!!8 = time for xs!!800 (!)
-O key does not help.
And the initial intention was to exploit the laziness under the
significntly more complex circumstances.
Namely, it is very natural for the lower-triangular matrix
inversion to prepare the upper rows of the result much cheaper
than the lower ones.
So, how to rule and predict the feature?
Sorry if I am missing something simple in the above script.
Regards,
Sergey Mechveliani, [EMAIL PROTECTED]
