Breaking Changes and Long Term Support Haskell

[Geoffrey Mainland]

>     I outlined one possible path to avoid this kind of issue: spend more
>     time thinking about ways to maintain compatibility. We had
>     proposals for
>     doing this with AMP.
>
>
> And on the other hand we also had a concrete proposal that didn't
> require language changes that was ridiculously popular. People had
> been talking about Applicative as a superclass of Monad for a decade
> before we finally acted upon the AMP. People had been talking about
> superclass defaulting for a decade. When do you cut off discussion and
> ship the proposal that has overwhelming support? If there is no
> process that enables this you can stall the process indefinitely by
> raising objections of this form. Such a situation is not without costs
> all its own.
>

I agree. It was certainly within the power of the committee to start a
clock and say something like "if we don't have a patch to GHC that
provides backwards compatibility for AMP within 1 year, we will push out
AMP as-is." Had I understand the implications of AMP at the time, or
even been aware that AMP was happening (I was actually actively working
on the GHC code base during that period), that certainly would have been
motivation for me to do something about it! *That* would be how one
could cut off discussion and ship a proposal.

I am not against changing the Prelude! But it sure would be nice if
-XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a
Haskell 2010 Prelude, both of which could be used with external packages
that themselves used the more modern Prelude. Maybe that's impossible.
Setting a firm deadline to finding a solution to the compatibility issue
would have been a way to compromise. Ideally, changing the Prelude
wouldn't require breaking code written to use an older version of the
Prelude. Yes, attaining that goal would require more work.

Evolving the Prelude and maintaining compatibility are not necessarily
mutually exclusive options.

Cheers,
Geoff