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

[Mario Blažević]

>>> 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?