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 <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
