I can't speak for anyone else, but This would be interesting and valuable for my own work too. 

One question I have is what sort of assumptions / optimizations will have to be different in strict vs lazy code?  What changes in the semantics  of doing fusion optimization? Does let lifting etc change substantially? Do strict variables not need the whole blackholing / thunk computation tracking that we need for lazy values (and would that result in any improvments to performance)? 




On Thu, May 2, 2013 at 12:30 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
Hi Simon and Max,

I've been thinking about Strict Core quite a bit lately. I'd like to take a stab at implementing it in GHC, if feasible. My motivations for implementing Strict Core are
  • generating faster code in a more robust manner, and
  • implementing strictness annotations at the type level in Haskell itself*.
Now, I don't know how much work this will be. What's you best time estimate (say, if you would do it vs if I would do it)?

My plan would roughly be as follows:
  1. Create a branch to develop on.
  2. Temporarily delete all the non-essential Core2Core transformations. This will let us get to a place where we have a functional compiler using Strict Core more quickly.
  3. Change CoreSyn.Expr to be Strict Core.
  4. Plumb the changes through the compiler until it compiles (and passes the tests) again.
  5. Once all tests pass, re-add all the Core2Core passes and make them use Strict Core.
  6. Rebase the commits so they can be merged nicely into the main branch.
How does that sound?

* I think this could be one of the most important changes in a long time to help Haskell in the "real world". It gives us a better way to talk about strictness than we have today, reducing time spent on chasing down space leaks. One we have strictness annotations in type, we could experiment with a Strict language pragma to make a whole module call-by-value.

Cheers,
Johan


_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs