On 5/21/13 2:22 AM, Simon Peyton-Jones wrote:

| 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".

Concretely: I propose making a major library/Prelude revision in order apply the various changes we've talked about forever but never do anything about because of compatibility concerns. In particular, the goal is to remove warts and streamline things, not to make any "language" changes, per se. Backward compatibility should be of no concern in enacting this proposal (though, of course, flagrant/unnecessary changes should be avoided). Think of it like the Python-2 to Python-3 transition, or similar. Below is a tentative list of such changes. This is offered as the beginning of a discussion rather than a final proposal per se. As part of the proposal, we should solicit feedback from the community at large (not just on this list) as well as the haskell' committee in order to ensure that we do as much as we can to clean things up. In particular, it'd be good to assemble the list of complaints/proposals prior to trying to resolve the details of any particular one, similar to the haskell' process I suppose. * Applicative => Monad. * Unify pure/return. Depends on Applicative => Monad. * Add join method to Monad, with default definitions for join/(>>=). * Remove fail from Monad (add Monad => MonadFail, if desired). * Make the (<$) method of Functor more official. When starting up ghci-7.6.1, it only gives (<$) qualified as (GHC.Base.<$) * Replace Enum by type classes which do not require partial functions. (I have a more concrete proposal for this one, which I'll put on Hackage in the next week or so.) This isn't a hot topic like the others, but it's part of the general concern about having partial functions as standard/required parts of the language. * Remove from the Prelude things which are not required for resolving circularity. This is highly controversial, but I think it would help minimize future issues. If desired, in order to reduce imports, we could have an Interlude which serves the kitchen-sink role of the current Prelude but which requires an explicit import rather than being implicit like the Prelude is. * Remove the list-monomorphic versions of Foldable/Traversable functions. And/or export them from a separate PegagogicalHaskell module for learners to use, such that they do not materially affect intermediate/advanced Haskellers. * This is a bit off-proposal, but: do not have every Control.Monad.* module re-export Control.Monad. Modules like Control.Monad.Foo should only export Foo-specific things; if people want the general tools they can import Control.Monad itself. This is related to the pain of standardizing on Foldable/Traversable. * Clean up the Monoid class, add a Semigroup superclass, etc. There was a lot of discussion about this a while back. We came up with a fair solution, but it'd be nice to revisit the discussion and tighten things up while we're at it. I'm sure there are others I'm forgetting, which is why this is only a suggested list. One thing I thing we should _not_ do is try to tackle the numeric hierarchy (except perhaps for cleaning up non-numeric superclasses like Eq, Show, etc). As much as I'd like to see the numeric hierarchy improved, the design space is very large and the solution is far from clear. Attempting to address that issue now would derail the conversation from the above changes and the general goal of streamlining and removing warts.

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

The big problems with backward compatibility are (a) the standard type classes ---especially their superclass constraints---, and (b) the Prelude. Unfortunately, both of these are baked into the language in such a way that it's extremely difficult to change them without breaking things. One of the reasons the above changes haven't been made already is due to holding out hope for finding some way to make the changes without losing backward compatibility. However, we haven't found any good way to do that over the years, and there are no promising new leads at the moment. -- Live well, ~wren