Re: Re: [Haskell-cafe] Re: A problem with par and modules boundaries...

You could probably see exactly what's happening in more detail by going through the Core output.
Thank you, this advice helped. The Core output indicates that function `test' evaluates the arguments to `parallelize' before it calls it. In other words, the call to `parallelize' is optimized as a strict function call -- which it is. The problem is that this optimization evaluates the arguments sequentially. Compiling with optimizations turned off regains the parallel execution.
I guess I will report this as a GHC bug. Or is it a feature request?
As Duncan suggessted, try with GHC head (grab a snapshot). `par` et al are much improved.
I already have, with the snapshot from 21st of April. It behaves the same as 6.8.2, except it runs for twice as long. I'd like to take back a part of what I said before, though: `parallelize' should be strict only in its second argument. Its strictness in the first argument should be the same as with `par`. Even though `parallelize x y' always evaluates both x and y, the following test works fine with optimizations even if `parallelize' is imported: main = putStrLn (snd $ parallelize undefined "Hello, World!") So the function is not strict, and I don't understand why GHC should evaluate the arguments before the call. Does anybody know of a pragma or another way to make a function *non-strict* even if it does always evaluate its argument? In other words, is there a way to selectively disable the strictness optimization?

On Sat, May 23, 2009 at 7:31 PM, Mario Blažević
Does anybody know of a pragma or another way to make a function *non-strict* even if it does always evaluate its argument? In other words, is there a way to selectively disable the strictness optimization?
parallelize a b | False = (undefined, undefined) | otherwise = a `par` (b `pseq` (a, b)) might do, unless strictness analysis is smart enough to know that the False guard is always, well, False. --Max

On Sat, May 23, 2009 at 11:34 AM, Max Rabkin
On Sat, May 23, 2009 at 7:31 PM, Mario Blažević
wrote: Does anybody know of a pragma or another way to make a function *non-strict* even if it does always evaluate its argument? In other words, is there a way to selectively disable the strictness optimization?
parallelize a b | False = (undefined, undefined) | otherwise = a `par` (b `pseq` (a, b))
might do, unless strictness analysis is smart enough to know that the False guard is always, well, False.
--Max _______________________________________________
GHC.Prim.lazy? Alex
participants (3)
-
Alexander Dunlap
-
Mario Blažević
-
Max Rabkin