Burning bridges

[Bardur Arantsson]

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,