Burning bridges

[Felipe Almeida Lessa]

IMHO, the problem is that the community isn't large enough to be able
to suffer a split.  Case in point: how are we going to have two GHC
HQs?

If we're going to burn bridges, perhaps we should follow a
Python-3-esque path of releasing a major upgrade together with:

  - A refactoring tool to aid with the transition.

  - A deadline of, say, 2-3 years during which the latest GHC for
current Haskell would receive bugfixes while GHC 8 moves along as
usual.

Cheers,

On Mon, May 20, 2013 at 7:49 PM, wren ng thornton <wren at freegeek.org> wrote:
> On 5/19/13 7:25 PM, Anthony Cowley wrote:
>>
>> I think this issue may be too big to rely on mailing list +1s. Is there
>> any precedent for having a web-based poll of some sort? We often get more
>> engagement in debates on IRC and /r/haskell than the mailing list, so let's
>> not let the choice of forum drive the result.
>
>
> Indeed.
>
> Personally, I'm all for blessing Foldable/Traversable as "built-in" and
> getting rid of the monomorphic legacy. But then, I'm also all for making
> Applicative a superclass of Monad, not having all the mtl modules re-export
> everything from Control.Monad, etc. However, all of these issues have a long
> history of discord, and that discord cannot be resolved on this list IMO.
>
> 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.
>
> Let us not forget the original reasons for many of these warts. Some of them
> stem from ignorance or oversight (superclasses of Monad); others stem from
> the desire to help newcomers (monomorphism); and others stem from
> circularities in the language definition (the existence of the Prelude). As
> Haskell has developed, we have learned more ---therefore we should not
> embrace prior ignorance---, our standard idioms have evolved ---therefore
> clinging to list-monomorphism *causes* confusion rather than alleviating
> it---, and we've tried to remove much of the circularity involved in
> desugaring the various built-in notations for lists, arithmetic sequences,
> do-notation, etc.
>
> 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. This won't solve
> all the problems, of course. We will still despair of the numeric hierarchy;
> we will still despair of the partial functions demanded by the Haskell spec;
> we will still worry about how to resolve things like MPTCs, type families,
> and all that. But at least we can finally put these particular ghosts to
> rest. Alas, to fork the language is to split the community. And while I
> advocate such drastic measures, they are measures which cannot be resolved
> either on this list or by the (intentionally conservative) haskell'
> committee.
>
> --
> Live well,
> ~wren
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



-- 
Felipe.