Johan

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.

Simon

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 02 May 2013 17:30
To: Simon Peyton-Jones; Max Bolingbroke
Cc: ghc-devs@haskell.org
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.

Cheers,
Johan

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

Reply via email to