Burning bridges

[Simon Peyton-Jones]

| I'm generally a staunch advocate of backward compatibility. However,
| these issues are ones where we've known the right answer for a long time
| (unlike refactoring the numeric type class hierarchy), and we've simply
| been unwilling to burn bridges in order to do the right thing. I love
| Haskell, and I respect the haskell' committee, but I think it's time to
| just burn it all down.
...
| With all that has changed in the last 15 years, I think it's high time
| to fork Haskell, tear off all the bandaids, and begin afresh. 

I'm not sure what you are proposing, concrete, by "fork Haskell".  

I think you are simply proposing some non-backward compatible library changes. Correct? And yes, it seems reasonable to do that every now and again. Indeed there's an active thread on splitting the base package http://hackage.haskell.org/trac/ghc/wiki/SplitBase, partly to make it easier to build a backward-compatible shim package.  So how non-backward-compatible would it all be?

I assume you guys have talked this to death, but is there no way to move on, while leaving a backward-compatible API?

Simon