> One can play funny games with GHC-3.00 and the following program
> (a small fragment of a Happy-generated parser):
>
> --------------------------------------------------------------------------
> module Foo ( happyParse ) where
>
> action_0 1 = \j tk _ -> action_1 j j tk (HappyState action_1)
>
> action_1 3 = error "Bar"
> action_1 _ = \i tk st@(HappyState action) sts stk -> action (-1) (-1) tk st sts
>(Just i : stk)
>
> happyParse = action_0 2 2 '-' (HappyState action_0) [] [] 2
>
> newtype HappyState b c =
> HappyState (Int -> Int -> b -> HappyState b c -> [HappyState b c] -> c)
> --------------------------------------------------------------------------
Great program! Thanks for isolating it.
Simon: pls add to regression suite
There are two problems. One is a long-standing bit of grubbiness
in the code generator; hence fun_result_ty panic. I've fixed that
(still grubbily, I fear).
GHC goes into a loop in the update analyser. Reason: the
recursive contravariance of HappyState. Consider:
action_1 j j tk (HappyState action_1) sts stk
= {unfold action_1}
action_1 (-1) (-1) tk (HappyState action_1) sts (Just j:stk)
= {unfold action_1 again}
...
Neither action_0 nor action_1 is recursive, but infinite unfolding
can still occur. This can cause the simplifier to loop, though
on this occasion it doesn't, but only because action_1 is
considered too big to unfold. But it does make the update analyser
loop, for some obscure reason. It wouldn't surprise me if the
strictness analyser looped too, but it doesn't.
For some reason there's no flag to switch off the update analyser.
It does very little good anyway, so just switch it off by force
in ghc/driver/ghc.lprl (look for -fupdate-anal).
I've known about the possibility of looping in the simpifier for some time, but
never seen it in a real program. I have no idea how to spot it in a clean way,
and without disabling lots of useful inlining. (I prevent looping mainly by
treating letrec carefully.) Ideas welcome
Simon
