Meta-point: backward compatibility

Aaron Denney wnoise at
Thu Apr 24 16:18:10 EDT 2008

On 2008-04-23, Simon Marlow <marlowsd at> wrote:
> Johan Tibell wrote:
>> An interesting question. What is the goal of Haskell'? Is it to, like
>> Python 3000, fix warts in the language in an (somewhat) incompatible
>> way or is it to just standardize current practice? I think we need
>> both, I just don't know which of the two Haskell' is.
> The stated goal is still for Haskell' to be a language that is stable 
> and relevant for large-scale development for several years to come.
> It is mainly a consolidation effort: that is, we aim to standardise 
> existing practice in the form of language extensions that are currently 
> implemented and widely used.  Having said that, the standardisation 
> process gives us the opportunity to critically assess the design of 
> these extensions, and the design of the system as a whole, and as a 
> result we may wish to make changes in order that the resulting language 
> does not have inconsistencies, design flaws, or critical omissions.

Given a fairly limited goal of "consolidating current practice", not
much should change.  And this is a very useful thing to do.  The problem
is that many of us don't see any opportunity for large change after
this.  We expect any changes in the hypothetical Haskell 2 (or 201x) to
be resisted tooth and nail by the larger crowd as Haskell grows.  And
there is a lot that clearly isn't battle tested in a reasonable new
form, though the current practice is widely agreed upon to be broken.
Examples include all monads having fail, rather than only those in a
subclass, monad not being a subclass of functor, and the whole numeric
hierarchy issue (which I don't think can be properly designed unless we
know whether it's going to be FDs or ATs, though, of course, designing
it for either would provide valuable experience for the limitations of
both),  Many of these are "mere" library changes, but library changes
that are nearly as fundamental as language changes, because of how tied
in the prelude is currently.  It's still not entirely straightforward to
replace the prelude with a custom one, which makes it harder to test
some of these changes in real world use.  All of these factors combine
to make the ones who get annoyed with these problems to want to shoehorn
in changes right now.

Aaron Denney

More information about the Haskell-prime mailing list