Implementing Strict Core

Simon Peyton-Jones simonpj at
Fri May 3 10:22:56 CEST 2013


I think this would be a very interesting thing to do.  But it would be a big project.  It is absolutely not routine work.

*         Strict Core is not just a little wibble.  It is a pretty big change.

o   It embraces multiple values.  These aren't the same as unboxed tuples because they include types, thus <Int, 7, 'x'>

o   It has multiple binders, in which early ones scope over later ones

o   It has both 'let' and 'valrec'.

o   I'm not sure how ANF-ised it should be

o   I am unsure about the interaction with user-written RULES

*         It needs to be extended with coercions and casts.  I don't think this would be too hard

*         How do unboxed tuples fit in?

*         I'm not certain whether delay/force should be done via encoding (as the paper suggests) or expressed directly.

*         Programs would get bigger

So it would force re-examination of many things.  In effect we'd go back three steps in order to position ourselves to move forward four or more.  The benefits would, I think, ultimately be substantial, but it'd take a while for them to manifest themselves.

If you wanted to undertake it I'd be happy to play an advisory role.  It's really hard to guess how long it'd take.  To get to something that stumbles along: weeks not days.  To get to something that routinely out-performs the baseline: months not weeks.

Step 0 should be to write a detailed specification, based on the paper, so that we all understand the language you are implementing.  Richards docs/core-spec/  is a model.


From: Johan Tibell [mailto:johan.tibell at]
Sent: 02 May 2013 17:30
To: Simon Peyton-Jones; Max Bolingbroke
Cc: ghc-devs at
Subject: Implementing Strict Core

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list