The motivation for this design is to make it so that
let
f = \x . E
in
... f y ...
Gives the same call stack as
... (\x . E) y ...
That is, inlining a function does not change the call stack. GHC
assumes that this is valid, so the call stack semantics should reflect that.
Intuitively it works like this: in the first version, the CCS attached
to the closure for f is some prefix of the CCS that will be in force at
the call site, and in that case we don't want to push anything on the
stack for the call. However, we might have:
let
f = scc "f" (\x . E)
in
... f y ...
and in this case we want to push "f" on the stack.
I don't claim that this always works (recursion in particular causes
problems) but it behaves in a sensible way in most cases, and it was the
best formulation I was able to find.
It remains to be seen whether there's a semantics that allows the
inlining equivalence to be formally proven; if you can do that I think
it would be a significant step forwards.
Cheers,
Simon
On 05/06/2014 09:57, Ömer Sinan Ağacan wrote:
Hi Maarten,
Where did you find that slides? I have slides for same talk(also
attached) but mine has a different definition for call: (on page 39)
call sapp slam = sapp ++ slam'
where (spre, sapp', slam') = commonPrefix sapp slam
This one works same with the implementation.
---
Ömer Sinan Ağacan
http://osa1.net
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
