On 05/24/2013 03:37 AM, wren ng thornton wrote:
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".
* 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. (snip misc. other suggestions.)
I'm a bit surprised I haven't seen anyone mention it, but the Go community have a tool which can automate a lot of the tedium of API transitions: http://blog.golang.org/2011/04/introducing-gofix.html Maybe I'm missing something, but surely this kind of tool (a "hlint on steriods", I guess) could be written for many of the breaking changes that have been suggested in recent days on this list. Gofix specifically doesn't try to fix absolutely *everything*, but it fixes all the trivial stuff which is extremely annoying, but automatable, such as import lists, module/function renames, etc. (For a recent example, see "catch".) Heck, one could even imagine building in a "--future" mode into such a program to handle changes "one version ahead" during the deprecation cycle (which I assume we're not getting rid of). It could, for example, start issuing appropriate warnings for the Applicative => Monad transition. (Which would mean that we wouldn't need ad-hoc modifications to GHC to support such transitions.) AFAICT having such a tool in the Go ecosystem has been a huge boon, at least while the language and APIs were developing and in the transition from Go 1.0 to 1.1. Regards,