Meta-point: backward compatibility
marlowsd at gmail.com
Wed Apr 23 17:21:30 EDT 2008
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.
The language design process is also an opportunity to re-assess existing
language features in the light of the wealth of experience gained over
recent years. A perfect example is the monomorphism restriction: we now
know that this aspect of the language really does surprise people in
practice, whereas this wasn't known, or at least wasn't as clear, at the
time that Haskell 98 was being designed.
As for the particular question of backwards-incompatible changes, here
are some criteria that Henrik Nilsson proposed early on, and I think are
still relevant (i'm sure he won't mind my reposting these from the
committee mailing list):
* If a proposed change breaks backwards compatibility, then it is
acceptable only if either
- very little existing code is likely going to be broken in
- + it is widely agreed that not addressing the issue really
would harm the long-term relevance of Haskell', and
+ it is widely agreed that attempting to maintain backwards
compatibility would lead to an unwieldy language design, and
+ the proposed design and its implications are well understood,
i.e. it has been implemented in at least one system and it has
been used extensively, or a strong argument can be made on
the grounds of, say, an underlying well-understood theory.
Libraries are another matter. We have in place mechanisms for
versioning libraries and specifying precise dependencies, so changes to
libraries are in a sense less fundamental than changes to the language
itself. We've already stated that libraries are to be standardised
separately, and I think it would also make sense for library standards
to be issued more regularly than standards for the language.
> -- Johan
> On Wed, Apr 23, 2008 at 2:16 PM, Chris Smith <cdsmith at twu.net> wrote:
>> There appears to be some question as to the backward compatibility goals
>> of Haskell'. Perhaps it's worth bringing out into the open.
>> >From conversations I've had and things I've read, I've always gathered
>> that the main goal of Haskell' is to address the slightly embarrassing
>> fact that practically no one actually writes code in Haskell, if by
>> Haskell we mean the most recent completed language specification. This
>> obviously argues strongly for a high degree of backward compatibility.
>> On the other hand, I am assuming everyone agrees that we don't want to
>> replicate Java, which (in my view, anyway) is rapidly becoming obsolete
>> because of an eagerness to make the language complex, inconsistent, and
>> generally outright flawed in order to avoid even the most unlikely of
>> broken code.
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
> Haskell-prime mailing list
> Haskell-prime at haskell.org
More information about the Haskell-prime