Meta-point: backward compatibility

[Simon Marlow]

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
      practice, or
    - + 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.

Cheers,
	Simon

> 
> -- 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.
>>
>>  --
>>  Chris
>>
>>  _______________________________________________
>>  Haskell-prime mailing list
>>  Haskell-prime at haskell.org
>>  http://www.haskell.org/mailman/listinfo/haskell-prime
>>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime