Simon PJ:
> That's just what I intend to do. I don't see Std Haskell as a big
> deal, but even little deals are worth completing rather than
> leaving as loose ends... and I'm more optimistic than Paul about
> the usefulness of Std Haskell. I would be happy to find a name
> that was less grand and final-sounding than 'Standard Haskell' though;
> but more final sounding than 'Haskell 1.5'.
Given the comments we have seen so far, there seem to be two major
issues at the heart of this `XX Haskell YY' business. Some may argue
they are just two aspects of the same issue, but separating them allows
for slightly different solutions to both aspects.
1. stability
people don't want their language to change just when (or even
before) they have managed to understand/implement/use/teach/write
about/.. the previous version
2. portability
those who make the effort to write useful programs in some
version of Haskell don't want to loose it all because of
language modifications that `break existing code'
One idea of the Standard Haskell effort was to solve 1 and 2 by fixing
one version of Haskell `forever'. The obvious problem with this is that
there are various open problems in the design of Haskell, and not only
language designers, but also *some* programmers would not accept Haskell
to be frozen as it is ("if it doesn't move, it is dead"). As I understood
it, the hope was that by fixing one version of Haskell as `the'
standard, the problems of teachers, book authors, and beginners would be
solved while the more ambitious part of the Haskell community would be
free to move on to some Haskell 2000 (without needing to care about
breaking existing code).
It should be clear from this description that I don't see how this could
possibly work for more than a couple of years;-)
Going back to the original issues, I think that the Standard ML
community has found a good solution for 1 (as for some other problems,
too). The idea is to compromise between stability and the need to
develop the language: instead of fixing the language forever, it is
fixed for some reasonable period of time (4-5 years should do, choose a
longer period if necessary). There is SML'90, SML'97, SML2000(?), and
programmers, teachers and textbook authors can be sure that their
efforts are not wasted (the standard is stable for at least four years,
and the next version can be covered in the next edition of books,
courses, and programs).
In the meantime, the implementations don't stand still, experimental
extensions to the standard are implemented and tested to be ready for
evaluation when the next update of the standard is due (indeed, the
standard updates may be driven by the quantity of mature extensions
available).
This brings us two problem 2. I don't know whether anyone has got a
solution for this in its full generality, but I think it is important to
recognize language evolution as a problem (and as a research issue? it
is similar enough to the schema evolution problem in database systems).
Once we agree that `breaking existing code' is an inherent part of
language evolution, we can look for solutions instead of trying to
discuss or define the problem away. Right now, I imagine the following
approach towards a first, but not necessarily final solution:
a. people have been working on Haskell parsers as separate programs
(they seem to be in beta now?), as well as various pretty printing
libraries
b. a Haskell xx parser written in Haskell xx can convert Haskell xx
programs into abstract syntax trees in Haskell xx (we would need to
keep all information in this case, including comments and indentation).
c. port the Haskell xx parser to Haskell yy, but keep two versions
with different input languages, so that we can parse both Haskell xx
programs and Haskell yy programs into Haskell yy ASTs.
d. use a Haskell yy function to convert Haskell yy ASTs for Haskell xx
programs into Haskell yy ASTs for Haskell yy programs.
e. pretty print the converted Haskell yy AST as a Haskell yy program.
This way, porting Haskell parsers (c) and providing the conversion
functions (d) will be the major efforts as far as porting Haskell xx
programs to Haskell yy programs is concerned, and the results of these
efforts can be shared by the Haskell community. Most programs should be
portable by running this one parse/convert/pretty-print program (several
of these converters could be composed to make the transition from
Haskell xx to Haskell yy to Haskell zz to ..).
I don't expect this to be a general solution for problem 2, but it would
certainly alleviate the problem: Currently, we cannot even change the
concrete syntax of Haskell because that would break existing code; with
Haskell parsers and pretty printers, we would not even have to define a
conversion function for such a simple problem: parse the old syntax and
pretty print the new.
Of course, we can still keep old executables or even old compilers
around, but I don't really consider this as a solution. However, trying
to support the one and only Standard Haskell while the gap to Current
Haskell becomes wider and wider with every year doesn't seem to make
sense to me either. Therefore: Standard Haskell 1998, or Standard
Haskell 1 (1998) appear to be reasonable choices - clearly different
from just another Haskell 1.x, but wide open for a Standard Haskell 2
(2005?-), after sufficient experience with various Haskell 2.x.
For what it is worth,
Claus
If each of these mails is worth 2 cents, where has all the money gone?-)
