why does the scrutinee of a CoreSyn.Case get bound to a variable?

[Simon Peyton-Jones]

Max has it right.  The main point is that Core is the subject of optimisation, and thus should have a pretty clear operational semantics. Roughly
	- 'let' means *allocate*
	- 'case' means *call*
So 
	let v = reverse xs in case v of { ... }
has different operational behaviour to
	case (reverse xs) of { ... }

Adding a binder to case expressions turned out to be a really good choice, I think.

Simon


| -----Original Message-----
| From: cvs-ghc-bounces at haskell.org [mailto:cvs-ghc-bounces at haskell.org] On
| Behalf Of Max Bolingbroke
| Sent: 27 February 2011 18:12
| To: Adam Megacz
| Cc: cvs-ghc at haskell.org
| Subject: Re: why does the scrutinee of a CoreSyn.Case get bound to a
| variable?
| 
| Consider this code:
| 
| On 27 February 2011 05:46, Adam Megacz <megacz at cs.berkeley.edu> wrote:
| >   let x = escrut
| >     in case x of
| >       Foo a b -> ebranch1
| 
| This allocates a thunk for escrut then immediately case scrutinises
| that thunk, forcing it
| 
| However, this code:
| 
| case x at escrut {
|     Foo a b -> ebranch1
|   }
| 
| (Where x is the case scrutinee binder) just enteres the code for
| escrut with a scrutinisation frame on the stack, with no intermediate
| heap allocation. Thus this code is faster.
| 
| So having the case wildcard lets GHC generate better code. Another
| reason is if GHC sees:
| 
| case x at escrut {
|   Foo a b -> ... Foo a b ...
| }
| 
| It can rewrite the (Foo a b) it sees in the branch as x directly,
| without having to go back and introduce a let-binding for escrut
| before the case expression. So it is more convenient to prevent
| reboxing when you have the scrutinee binder.
| 
| I'm sure Simon will have some other reasons it is good, but those are
| the 2 that come to mind.
| 
| Cheers,
| Max
| 
| _______________________________________________
| Cvs-ghc mailing list
| Cvs-ghc at haskell.org
| http://www.haskell.org/mailman/listinfo/cvs-ghc