Re: Meta-point: backward compatibility

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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime