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

[Mario Blažević]

On Sat 23/05/09  2:51 PM , Duncan Coutts duncan.coutts at worc.ox.ac.uk sent:
> On Sat, 2009-05-23 at 13:31 -0400, Mario Blažević wrote:
> ...
>> So the function is not strict, and I don't understand
>> why GHC should evaluate the arguments before the call.
> 
> Right, it's lazy in the first and strict in the second argument. As far
> as I can see we have no evidence that is is evaluating anything before
> the call.


When I look at the Core definition of `test', it begins with


    \ (n1axl::integer:GHCziIntegerziInternals.Integer)
      (n2axn::integer:GHCziIntegerziInternals.Integer) ->
        %let as1sU :: integer:GHCziIntegerziInternals.Integer =
               base:DataziList.prod1
               (main:Main.factors2
                (base:DataziList.prod1
                 (base:GHCziNum.upzulist main:Main.lvl main:Main.lvl n1axl)
                 base:DataziList.lvl1))
               base:DataziList.lvl1
        %in %case integer:GHCziIntegerziInternals.Integer (ghczmprim:GHCziPrim.parzh
                                                           @
integer:GHCziIntegerziInternals.Integer
                                                           as1sU)
            %of (dsapq::ghczmprim:GHCziPrim.Intzh)


To my untrained eyes, this looks like it's evaluating

> product $ factors $ product [1..n1])

which is the first argument to `parallelize'. I assume that %case in
Core evaluates the argument to WHNF, just like case in Haskell.

Then again, I could be completely misinterpreting what Core is, because
I can't find any call to `parallelize' before or after that. It appears
to be inlined in Core, regardless of whether the pragma

> {-# INLINE parallelize #-}

is there or not. Actually, I can't see any effect of that pragma in the
core files whatsoever, but it certainly has effect on run time.

>> 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?
> 
> Yes, which is what pseq and par already do.
> 
> If there's a bug, we need to reproduce it and report it. I cannot
> reproduce it.

If you mean that you can't reproduce anything that's contrary to the
specification, that's not saying much: there are practically no guarantees on
what `par' is supposed to accomplish. If you mean you can't reproduce anything
you wouldn't expect, pray explain what is going on, because everybody else seems
to be surprised. Or do you mean to say that *your* installation of GHC behaves
the same when the function `parallelize' is defined in the same module and when
it's imported?