Haskell 1.3 nearly ready
The Haskell 1.3 effort is nearly complete. Although a new report is not yet complete, all proposed changes to the language as well as the new Prelude are now available for public comment. These documents are available on the web at http://www.cs.yale.edu/HTML/YALE/CS/haskell/haskell13.html Any feedback is appreciated! A new report should be ready soon. John Peterson [EMAIL PROTECTED] Yale Haskell Project
Changes in Haskell 1.3 since last posting
If you have looked at the Haskell 1.3 material previously, the main difference is that all issues regarding records have finally been resolved. In addition, a number of smaller changes have been made: `module M' is used in export lists instead of `M..' The text of the new Prelude is now included. The Bounded class has been added to the Prelude A few more monadic functions for imperative-style programming have been added. The descriptions of the new features have often been clarified and elaborated. John
Re: Changes in Haskell 1.3 (Qualified names)
The proposed change should not break too much code. The `.' is only treated specially after a constructor. This will break: tstpatp9= (P_cons P_write.P_cons P_read) P_empty_list because of the P in P_write but this will be fine: proc_emulator f = prm_em.f Since constructors appear relatively infrequently in compositions, this should be a rather painless change in the syntax. We did consider other punctuation besides `.' but almost everything is taken or is visually unappealing; `.' has a certain amount of tradition behind it. John
Re: adding instances to (,)
Your error messages from ghc are correct: you have violated the infamous C-T rule (section 4.3.2, page 32) which restricts instance declarations to the module containing either the class or the datatype. Since (,) and Num are both in the prelude, you can't compile this in official Haskell 1.2. You could define your own datatype isomorphic to (,) but you won't get the nice notation. This should be legal in Haskell 1.3 (once it's done!) - the C-T rule can be quite annoying so it's being relaxed. Just remember: HUGS is not Haskell :-). John Peterson Yale Haskell Project
1.3 report available from Yale
You can also get the 1.3 report from Yale via ftp: on haskell.cs.yale.edu look in pub/haskell/report. John
Prelude Problems
Ignoring the issue of whether the current Prelude would be improved using a more general class heirarchy, let me point out the real failing of Haskell here. The problem is not so much that the prelude doesn't work the way you want it to, but rather that there is no way to build your own prelude using the conventional names for things such as + or -. Quite a bit of the basic Haskell vocabulary is in PreludeCore, including the entire class structure of the Prelude and all associated class methods. Once in PreludeCore, these names cannot be redefined or hidden. There is no compelling reason for this - I think at the very least the 1.3 folks should eliminate PreludeCore in some way so that the system no longer reserves all of the numeric operators for it's own. At least this way we will not be forced into this `one Prelude fits all' situation. John Peterson Yale Haskell Project
Draft of Haskell 1.4 Report is now available
We would like to make the current draft of the Haskell 1.4 report available for public comment. To see the new report and find out about changes from Haskell 1.3 please look at http://haskell.cs.yale.edu/1.4/haskell-report.html There is not much new material in the 1.4 report - it is substantially the same as 1.3. Please send any comments to me directly. Thanks, John Peterson Yale Haskell Project [EMAIL PROTECTED]
Preliminary Haskell 1.3 report now available
Announcing a preliminary version of the Haskell 1.3 report. The Haskell 1.3 report is nearly complete. All technical issues appear to be resolved and the report is nearly ready. The report will be finalized April 19. Any comments must be submitted by April 15. We do not anticipate making any serious technical changes is the current version. The report is being made available both on the web and as a .dvi file. A summary of changes made in the Haskell 1.3 report can be found in http://www.cs.yale.edu/HTML/YALE/CS/haskell/haskell13.html This has pointers to the html version of the report. The dvi file is available via anonymous ftp at ftp://haskell.cs.yale.edu/pub/haskell/report/new-report.dvi.gz Send comments or questions to [EMAIL PROTECTED]
Re: Haskell 1.3
We are still in the middle of a bunch of minor last-minute changes. While the technical aspects of Haskell 1.3 are stable, we're still fiddling with the prelude and the wording of the report. We've now set a `final' final release date at May 1. As before, the working version of the report is available via the web at http://haskell.cs.yale.edu/haskell-report/haskell-report.html More importantly, there is a lot of work going on to get the implementations ready. I hope people will be able to start using Haskell 1.3 soon after we release the report. John Peterson [EMAIL PROTECTED] Yale Haskell Project
Status of Haskell 1.3
The Haskell 1.3 report is nearly done. The text of the report is complete - I'm working on indexing and web pages. We also have an initial cut at the Library Report. If you are interested in seeing the new report on the web, look at http://haskell.cs.yale.edu/haskell-report/haskell-report.html We expect the report will be complete in another week - the web page will have the latest information and I will be announcing to comp.lang.functional. No implementations of 1.3 are available yet, but we expect all the major Haskell systems to conform to the new report soon. Announcements will be made to this list. Although the report is stable, the related web pages are still under construction. Please have patience! John Peterson Yale Haskell Project
Haskell 1.3 Report is finished!
The Haskell 1.3 Report is now complete. A web page with the entire report and other related information is at: http://haskell.cs.yale.edu/haskell-report/haskell-report.html This new report adds many new features to Haskell, including monadic I/O, standard libraries, constructor classes, labeled fields in datatypes, strictness annotations, an improved module system, and many changes to the Prelude. The Chalmers compiler, hbc, supports most (all?) of the new 1.3 features. The Glasgow compiler will soon be upgraded to 1.3. A new version of Hugs (now a combined effort between Mark Jones and Yale) will be available later this summer. A postscript version of the report is available at ftp://haskell.cs.yale/edu/pub/haskell/report/haskell-report.ps.gz. This file should be available at the other Haskell ftp areas soon. John Peterson [EMAIL PROTECTED] Yale Haskell Project
Re: Type synonyms and coercions, again
To answer your questions ... - Is the above view of type synonyms really equivalent to the Haskell report's definition? (Above view: consider the type and it's synonym to be distinct but with implicit bidirectional coercion) Almost. In some places, synonyms are not allowed. Your scheme would seem to allow synonyms anywhere at all. (Instance declarations cannot use synonyms). - If so, wouldn't it be a better alternative which allows the introduction of more general coercion functions later? Type synonyms are a very simple, syntactic way of abbreviating types. As presently used, coercions don't make sense. A synonym is simply an abbreviation used in type signatures. - Can it be used to replace or simplify the notion of `newtype'? (Why were `newtype' declarations introduced in the first place?) Newtype is an entirely different creature. With newtype, explicit coercions guarantee that a value has a single, unique type (principal type). Type synonyms don't get in the way or principal types because they are just syntactic abbreviations and can be expanded away. The place where this all becomes crucial is when looking up instances associated with types. Type synonyms are always removed when looking up instances. If you have x :: String then when an instance associated with x is needed, it will always expand String to [Char] and fetch instances associated with lists. Now if the types created by type synonyms were somehow distinct (capable of carrying different instances), you would have to be able to know exactly whether something is String or [Char] to understand the semantics of the program. If the coercions are implicit, things get very confusing. Newtype carries separate instances (unlike synonyms) but requires explicit coercion so there is no possibility of confusion. The only special thing about newtype is that it implies no additional representational overhead, unlike using an ordinary wrapper type (I'm convinced there's never any overhead for newtype but Mark Jones isn't; but we both agree that the overhead is minimal). Representational efficiency and program clarity are the reasons to have newtype instead of using wrapper types. In the bigger picture, though, the concept of `make a type T whose internal structure is identical to another type U but which is distinct' is a common idiom in other programming languages that we felt should be in Haskell directly and efficiently. John Peterson [EMAIL PROTECTED]
Comparing different Yale Haskell systems
Different Versions of Yale Haskell Compared --- There are currently three different platforms running Yale Haskell. Yale Haskell runs on Lucid Common Lisp, CMU Common Lisp, and AKCL. This document describes the differences between these systems. Differences in performance between the different versions of Yale Haskell reflect the underlying Lisp systems. The better the Lisp system, the better the Haskell system built on it. However, getting optimal performance from our Haskell system on top of a Common Lisp system requires careful attention to the underlying compiler. Small changes in the optimization settings or the addition of crucial declarations can make significant differences in performance. We have been doing most of our work using the Lucid system and have tuned it more than the others. These comparisons are greatly influenced by the amount of time we have spent tuning the system: the CMU version has been tuned only a little and the AKCL version hardly at all. Methodology The following timings are only approximate. They were obtained using the timing functions provided by the Common Lisp system. All timings were done on an unloaded Sparc 1. No attempt was made to account for garbage collection, differences in heap size, or similar factors. We don't intend these benchmark results to be taken as an exhaustive comparison of the different Lisp implementations involved. Portability We have had no trouble moving our system to different hardware platforms under the same Lisp system. Since the release is in source form, we expect that users will be able to build on any hardware platform supported by one the Lisps we have ported to. Probably the only real constraint on portability is the requirement for a large virtual memory space. >From the comp.lang.lisp FAQ: Lucid Common Lisp runs on a variety of platforms, including PCs (AIX), Apollo, HP, Sun-3, Sparc, IBM RT, IBM RS/6000, Decstation 3100, Silicon Graphics, and Vax. CMU Common Lisp is free, and runs on Sparcs (Mach and SunOs), DecStation 3100 (Mach), IBM RT (Mach) and requires 16mb RAM, 25mb disk. Kyoto Common Lisp (KCL) is free, but requires a license. Conforms to CLtL1. It is available by anonymous ftp from rascal.ics.utexas.edu [128.83.138.20], cli.com [192.31.85.1], or [133.11.11.11] (a machine in Japan) in the directory /pub. AKCL is in the file akcl-xxx.tar.Z (take the highest value of xxx). To obtain KCL, one must first sign and mail a copy of the license agreement to: Special Interest Group in LISP, c/o Taiichi Yuasa, Department of Computer Science, Toyohashi University of Technology, Toyohashi 441, JAPAN. Runs on Sparc, IBM RT, RS/6000, DecStation 3100, hp300, hp800, Macintosh II (under AUX), mp386, IBM PS2, Silicon Graphics 4d, Sun3, Sun4, Sequent Symmetry, IBM 370, NeXT and Vax. A port to DOS is in beta test as math.utexas.edu:pub/beta2.zip. We have not yet completed ports of Yale Haskell to any other Lisp implementations, although we are likely to do so in the future. System Size The overall size of the Haskell system depends on the size of the underlying Lisp system and how much unnecessary Lisp overhead has been removed for the system. We have removed large Lisp packages (like CLOS or CLX), but have not attempted to do any tree shaking. The size of the saved images (including the Lisp system, the Haskell compiler, and the compiled prelude) is Image Size: Lucid 10 meg CMU 18 meg AKCL11 meg The larger size of the CMU system is probably an artifact of their way of saving the system. Compilation Time There are three possible ways to compile a Haskell program. All Haskell programs must be translated into Lisp. The generated Lisp can then be interpreted, using no additional compilation time; compiled with a `fast' but nonoptimizing Lisp compiler; or compiled with the `slow' compiler that aggressively attempts to perform as many optimizations as possible. To time the `fast', nonoptimizing compiler, we have been using (PROCLAIM '(OPTIMIZE (SPEED 3) (SAFETY 0) (COMPILATION-SPEED 3))) and for the `slow', fully optimizing compiler, we have been using (PROCLAIM '(OPTIMIZE (SPEED 3) (SAFETY 0) (COMPILATION-SPEED 0))) so that the only difference is in the COMPILATION-SPEED quality. Lucid does, in fact, provide two completely different compilers that correspond to these optimize settings. For all three implementations, it appears that that the effect of a higher compilation speed setting is primarily in being less aggressive about inlining and making use of type declarations. The Haskell system itself (including the Prelude) is normally built with the fully optimizing compiler. To show just the Haskell to Lisp compilation time, here are the times needed to compile the Prelude (about 2500 lines of Haskell code). This does not include the time in the Lisp compiler or starting up the system.
