Re: Felleisen on Standard Haskell
In respone to: ? From: Simon L Peyton Jones [EMAIL PROTECTED] ? Subject: Re: Felleisen on Standard Haskell ? Date: Tue, 04 Aug 98 08:54:48 +0100 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'. I'd like to throw in my 0.02 euro: What about "Interim Haskell"? This would reflect that something better is in preparation but not ready for the show yet. Gabor
Re: Felleisen on Standard Haskell
In any case, I hope that Simon will follow his urge to get Standard Haskell done with Real Soon Now, even if there is no overwhelming consensus on certain issues, so that we can then concentrate on Haskell 2. 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'. Matthias's points are good ones, but premature for Haskell I think, which is still moving pretty fast. Indeed, for some reason, faster of late. Simon
Re: RE: Felleisen on Standard Haskell
That said, the more I think about it, I don't really believe that "Standard Haskell" will accomplish much. The fact is that everyone wants many of the features in Haskell 2, and so even today would prefer using an implementation that is probably not fully compliant with anything that is "official" at all. I feel that way, but I think that Richard Bird and other people using Haskell in teaching may disagree. (Come to think of it, wouldn't that category include you too?) It's not only people who use Haskell for teaching that want stability. If you've used Haskell for some real project where the current Haskell is adequate (which, IMHO, is quite a few) you may not want to rewrite gazillion lines of code. I was one of the proponents of Standard Haskell partly because I have such programs. I'm sure there are others who don't care about the latest features, but just want to keep their programs running. I think Standard Haskell is a good thing since it opens up the possibility of making non-compatible changes in Haskell 2. -- Lennart
Re: Felleisen on Standard Haskell
Simon writes: 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'. What about "Haskell 98" ? Sounds more final as 1.5 but less final as a Standard :-) -- Daan
Re: Felleisen on Standard Haskell
Simon L Peyton Jones wrote: 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'. `Teaching Haskell' is an obvious option, but might put too many non-academics off. So, considering its purpose, what about `Stable Haskell'? (The main drawback is, of course, that the phrase `horses for courses' springs to mind :-) [Just couldn't resist sharing that one with you all!] -- David post: DERA Malvern, St Andrews Road, Malvern, WORCS WR14 3PS, ENGLAND mailto:[EMAIL PROTECTED] ** phone: +44 1684 895112 ** fax: +44 1684 894389 [The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body.]
Re: RE: Felleisen on Standard Haskell
At 10:12 +0200 98/08/04, Lennart Augustsson wrote: It's not only people who use Haskell for teaching that want stability. If you've used Haskell for some real project where the current Haskell is adequate ... I think Standard Haskell is a good thing since it opens up the possibility of making non-compatible changes in Haskell 2. I think this question has been up before, the continued creativity of a language versus its use as a programming language, which requires a conservative approach. The dual approach Haskell 2 vs. Standard Haskell sounds good from this perspective. I should note that if one want the programs of an earlier version of a computer language should be able top run on a later version, that can be described by a monad. So why not implement an upgrade monad in Haskell? -- It would solve the problem once and for all. Hans Aberg * Email: Hans Aberg mailto:[EMAIL PROTECTED] * Home Page: http://www.matematik.su.se/~haberg/ * AMS member listing: http://www.ams.org/cml/
RE: Felleisen on Standard Haskell
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'. That sounds like a good idea. But why don't we just be honest and call it Haskell--? (Or maybe "(-1) Haskell"? :) Unfortunately, that's not even a legal section because of the funny rules for unary minus...) Hm... "Pre-Haskell"? --FC
Re: RE: Felleisen on Standard Haskell
Lennart wrote: It's not only people who use Haskell for teaching that want stability. If you've used Haskell for some real project where the current Haskell is adequate (which, IMHO, is quite a few) you may not want to rewrite gazillion lines of code. I'd like to second that. I have two projects (http://www.informatik.uni-leipzig.de/~joe/rx/index.html and http://www.informatik.uni-leipzig.de/~joe/juggling/drops/index.html) don't know how much they could be called "real", (they're real for me at least) but I'd very much prefer a stable Haskell for them. best regards, -- Dr. Johannes Waldmann Institut fur InformatikUniversitat Leipzig [EMAIL PROTECTED] http://www.informatik.uni-leipzig.de/~joe/ Augustusplatz, D-04109 Leipzig, Germany, Tel/Fax (+49) 341 97 32 204/209
Re: Felleisen on Standard Haskell
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
Re: Felleisen on Standard Haskell
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'. Let's drop the name Standard Haskell for now. I think Haskell 1.5 sounds just fine, and is much truer to what's actually going on, given Haskell 2 on the horizon. The name doesn't even need to sound definitive. The point is that *we* consider 1.5 a standard, and pledge to support it in our implementations. The users of it aren't going to care what the name is, as long as the textbook examples work ;-) --Jeff
