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