Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : supercompiler
http://hackage.haskell.org/trac/ghc/changeset/2cf836097a4b5afb3cbbb28d48f00c894219a725 >--------------------------------------------------------------- commit 2cf836097a4b5afb3cbbb28d48f00c894219a725 Author: Max Bolingbroke <batterseapo...@hotmail.com> Date: Wed Jul 4 18:15:13 2012 +0100 Comment only >--------------------------------------------------------------- .../supercompile/Supercompile/Drive/Process3.hs | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/compiler/supercompile/Supercompile/Drive/Process3.hs b/compiler/supercompile/Supercompile/Drive/Process3.hs index 13f4496..83c4393 100644 --- a/compiler/supercompile/Supercompile/Drive/Process3.hs +++ b/compiler/supercompile/Supercompile/Drive/Process3.hs @@ -455,10 +455,11 @@ memo opt init_state = {-# SCC "memo'" #-} memo_opt init_state -- -- This problem doesn't occur without type generalisation because the h functions mentioned freely by the fulfilments/ -- partial fulfilments (latent on the stack) at the time we made the promise we are rolling back to can *only* mention - -- promises that we have already made! + -- promises that we already made at that time! -- -- WITH type generalisation we go and modify those existing fulfilments to point into the portion of the stack which -- is in danger of rollback. + -- (A similar problem would occur if we messed about with previous fulfilments when we detected a MSG opportunity.) -- -- A formalisation of this idea is below: -- _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
