Haskell 1.3 nearly ready

1995-12-12 Thread peterson-john

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


Any feedback is appreciated!  A new report should be ready soon.

  John Peterson
  Yale Haskell Project

Re: adding instances to (,)

1995-07-24 Thread peterson-john

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

Prelude Problems

1995-03-10 Thread peterson-john

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'

John Peterson
Yale Haskell Project

Preliminary Haskell 1.3 report now available

1996-03-06 Thread peterson-john

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


This has pointers to the html version of the report.

The dvi file is available via anonymous ftp at

Send comments or questions to [EMAIL PROTECTED]

Status of Haskell 1.3

1996-05-07 Thread peterson-john

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


We expect the report will be complete in another week - the web page
will have the latest information and I will be announcing to

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!

1996-05-15 Thread peterson-john

The Haskell 1.3 Report is now complete.  A web page with the entire
report and other related information is at:

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 
This file should be available at the other Haskell ftp areas soon.

   John Peterson
   Yale Haskell Project

Comparing different Yale Haskell systems

1992-09-30 Thread peterson-john

 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.


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.


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 [],
  cli.com [], or [] (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

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


and for the `slow', fully optimizing compiler, we have been using


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