[Haskell-cafe] Lazy in either argument?

[Tim Chevalier]

On 7/26/07, Lennart Augustsson <lennart at augustsson.net> wrote:
> The non-termination is (probably) due to the fact that you can have uninterruptible threads in ghc.
> If a thread never allocates it will never be preempted. :(
>

To elaborate on that, the different behavior between the two versions
of Dan's code, one with and one without a type signature, happens
because f compiles like so if the type signature isn't given (this is
the STG code):

f_ri5 = \u [] let-no-escape { f1_sPY = NO_CCS[] \u [] f1_sPY; } in  f1_sPY;
SRT(f_ri5): []

and like so if the type signature is given:

f_ri5 = \u srt:(0,*bitmap*) [] f_ri5;
SRT(f_ri5): [f_ri5]

If you look at the resulting asm code, the second version of f_ri5
compiles to a loop that allocates on each iteration, whereas the body
of the let in the first version of f_ri5 compiles to just:
sPY_info:
	jmp sPY_info

(Adding f to the export list so that its SRT is empty doesn't change
anything, btw.)

This is all with -Onot.

So I find this a little confusing. Why is f = let f_1 = f_1 in f_1
compiled so differently from f = f? It seems like f = f should also
compile to a loop that doesn't allocate anything. And from the user's
perspective, it seems somewhat strange that adding or removing a type
signature changes the semantics of their code (although I guess you
could make the argument that if you're dealing with threads and
nonterminating code, all bets are off.) Can someone better acquainted
with the code generator than me explain the rationale behind this?

Cheers,
Tim

-- 
Tim Chevalier* catamorphism.org *Often in error, never in doubt
"Religion is just a fancy word for the Stockholm Syndrome."  -- lj
user="pure_agnostic"