Release 1.18 of nhc98

Should I use nhc98 or yhc?

Yhc is an offshoot of nhc98, with considerable improvements to the clarity of the implementation code. It is intended to be faster and better than nhc98. However, the project is still incomplete, and you should be aware that, in the meantime,
  • nhc98's build system is much more robust than Yhc's. It is more likely to just work first time (unless you happen to want to build your compiler on Windows without mingw, and using MS VC++, in which case Yhc is definitely the way to go.)
  • nhc98 correctly builds more programs than Yhc. Mainly, Yhc is missing many standard libraries.
  • nhc98-built programs run on average 20-40% faster than Yhc-built programs. In theory, Yhc should be faster, because Yhc executes fewer bytecodes, and they are simpler, but in practice nhc98 still wins. See the nobench results.

Why use the nhc98 Haskell compiler?

Because it is easy to install.
nhc98 is very easy to configure and build, even for new machines which have never seen a Haskell compiler before, and it copes with Unix, Windows, and MacOS X without difficulty.
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 [1] 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 up to 15x faster than Hugs).
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 [2], 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 augmented redex trails [2,3], which gives you much, much more. The Hat system (distributed separately from nhc98) provides three different and complementary browsing tools for exploring the runtime behaviour of your program.

References

[1] 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. [FTP site]

[2] 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. [FTP site]

The latest updates to these pages are available on the WWW from http://www.haskell.org/nhc98/

This page last updated: 28th Feb 2007
York Functional Programming Group