| 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