What does unsafePerformIO do to the stack
simonmarhaskell at gmail.com
Fri Feb 8 05:29:20 EST 2008
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!
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
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.
More information about the Glasgow-haskell-users