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