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: [email protected] [mailto:[email protected]] On
| Behalf Of Max Bolingbroke
| Sent: 27 February 2011 18:12
| To: Adam Megacz
| Cc: [email protected]
| 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 <[email protected]> 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@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@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
| [email protected]
| http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
