Release 1.14 of nhc98
Why use the nhc98 Haskell compiler?
- Because it is easy to install.
- Some people find ghc and hbc difficult to install
on their machine, particularly if their machine is not a unix PC.
nhc98 is very easy to configure and build, even for new machines
which have never seen a Haskell compiler before.
- Because you have a small machine.
- nhc98 is designed for space-efficiency. Compile the same
program under either ghc or hbc, and compare it with
that produced by nhc98. Generally, nhc98 produces
much smaller executables, and runtime space usage is also
very much smaller. (With the nhc98 Binary library 
you can compress your heap data in addition to the normal savings.)
Expect to pay a speed penalty though - programs produced by
nhc98 run between 2x and 6x slower than with ghc
or hbc (although they are still rather faster than
- Because you're a software developer.
- nhc98 comes with comprehensive tool support - hmake, hi, greencard,
heap and time profiling, and two debuggers.
Are you fed up waiting for ghc to compile your programs?
nhc98 can be pretty quick at compiling, even though it
is not as fast as hbc. For development work, it can also
provide a useful check that you are sticking to the Haskell 98
standard and avoiding compiler-specific extensions.
- Because your programs have strange space behaviour.
nhc98 has the most advanced heap profiler in the Haskell
world , allowing you to observe in very fine detail exactly what is
happening to the heap. Profile types include producer, construction,
retainer, biography, and lifetime - and any combination thereof.
- Because your program crashes, or produces the wrong output.
nhc98 has two sets of debugging facilities.
First, Andy Gill's HOOD
library together with his XML-based debugging browser.
Second, York's advanced Hat tracing system based on
advanced redex trails [2,3], which gives you much, much more.
The Hat system provides three different and complementary browsing
tools for exploring the runtime behaviour of your program.
hat-observe gives you HOOD-like observations of the
behaviour of functions, but with no need to annotate the program
being studied. In hat-trail, browsing proceeds
backwards from the error message or suspicious output value,
observing and exploring the reduction history of parts of the
computation. By answering the question "What function application caused
the evaluation of this expression?" at each stage, it is possible to
narrow down program bugs quickly. Finally, hat-detect is
an algorithmic debugger which asks you questions about the program
and then automatically pinpoints the source of an error.
 The Bits Between The Lambdas - Binary Data in a Lazy Functional Language,
Malcolm Wallace and Colin Runciman, Proceedings of the International
Symposium on Memory Management, Vancouver, Oct 1998.
 Tracing Large Functional Computations Using Partial Redex Trails,
Jan Sparud and Colin Runciman, Proc 9th IFL, St Andrews,
Springer LNCS 1467, Sept 1997.
 Tracing Lazy Functional Computations Using Redex Trails, Jan Sparud
and Colin Runciman, Proc 9th PLILP, Southampton, Springer LNCS
1292, Sept 1997.
 Heap Profiling for Space Efficiency, Colin Runciman and Niklas Röjemo,
2nd Intl School on Advanced Functional Programming, pp.159-183,
Springer LNCS 1129, Olympia WA, Aug 1996.
The latest updates to these pages are available on the WWW from
This page last updated: 2002.06.13
York Functional Programming Group