What does unsafePerformIO do to the stack

[Simon Marlow]

Bernd Brassel wrote:
> There is another point that makes me wonder now. If the update frame for
> the recursive call is the problem then my solution with foreign C
> functions would produce a bad stack also. But this is not the case.
> The code looks now like this:
> 
> 
> sim []     = True
> sim (_:xs) = yags (sim xs)
> 
> ref = cinitialize
> 
> yags x = replace (C_Ref ref) x ()
> 
> And it is running within 0.15M of stack.
> Did your explanation also account for this phenomenon?
> 
> Sorry to take that much time off you with this!
> Bernd

The stack of update frames is not in itself a problem, because stack 
squeezing removes them leaving you with O(1) stack again.  The problem with 
unsafePerformIO was that the duplication-protection was interfering with 
stack squeezing.

Regarding sharing analysis, we did used to have an update analyser in GHC, 
but it was expensive to run and rarely gave worthwhile benefits, so 
eventually we dropped it.  Perhaps there are some trivial examples of 
unshared thunks that we could spot, though.

Cheers,
	Simon