patch applied (ghc): TickBox representation change
Simon Marlow
simonmarhaskell at gmail.com
Mon Dec 4 04:52:57 EST 2006
Simon Peyton-Jones wrote:
> I had a look at what you did. Generally looks good. Much better than the Note version, as I hope you agree! (You seem to have deleted quite a bit of code!)
>
> Here's a qn. I thought you were going to do ticks like this:
> dsExpr (HsTick a e) = tick{a} e
> but instead you have
> dsExpr (HsTick a e) = case tick{a} of DEFAULT -> e
> I think that both are probably fine, but the implications are not clear to me.
It's perhaps because I suggested we use the case form. If we had
tick{a} e
then we really don't want e compiled to a thunk. So somehow this must turn into
the case form in the back end:
case tick{a} of DEFAULT -> e
but just declaring tick{a} to be strict won't do this: it'll give you
case e of DEFAULT -> tick{a} e
Perhaps this still works, I don't know. To me it seems like a longer way
around; the case form more directly says what you want to happen. But maybe I'm
missing something?
The former seems more robust somehow. For example if we have
> case tick{a} of DEFAULT -> ....(case tick{a} of DEFAULT -> ...)
> GHC might eliminate the inner tick. Would that be OK (after all, you're only checking coverage, and it's covered)?
One of the suggestions was to use a PrimOp (like the foreign call op) for tick,
which would prevent the simplifier from eliminating the inner tick because the
PrimOp would be declared as having side effects.
Cheers,
Simon
More information about the Cvs-ghc
mailing list