1. Introduction to GHC

This is a guide to using the Glasgow Haskell compilation (GHC) system. It is a batch compiler for the Haskell 1.4 language, with support for various Glasgow-only extensions.

Many people will use GHC very simply: compile some modules---ghc -c -O Foo.hs Bar.hs; and link them--- ghc -o wiggle -O Foo.o Bar.o.

But if you need to do something more complicated, GHC can do that, too:

ghc -c -O -fno-foldr-build -dcore-lint -fvia-C -ddump-simpl Foo.lhs

In this document, we assume that GHC has been installed at your site as ghc. The rest of this section provide some tutorial information on batch-style compilation; if you're familiar with these concepts already, then feel free to skip to the next section.

1.1 The (batch) compilation system components

The Glorious Haskell Compilation System, as with most UNIX (batch) compilation systems, has several interacting parts:

1. A driver ghc ---which you usually think of as ``the compiler''---is a program that merely invokes/glues-together the other pieces of the system (listed below), passing the right options to each, slurping in the right libraries, etc.
2. A literate pre-processor unlit that extracts Haskell code from a literate script; used if you believe in that sort of thing.
3. The Haskellised C pre-processor hscpp, only needed by people requiring conditional compilation, probably for large systems. The ``Haskellised'' part just means that #line directives in the output have been converted into proper Haskell {-# LINE ... -} pragmas. You must give an explicit -cpp option for the C pre-processor to be invoked.
4. The Haskell compiler hsc, which---in normal use---takes its input from the C pre-processor and produces assembly-language output (sometimes: ANSI C output).
5. The ANSI C Haskell high-level assembler :-) compiles hsc's C output into assembly language for a particular target architecture. In fact, the only C compiler we currently support is gcc, because we make use of certain extensions to the C language only supported by gcc. Version 2.x is a must; we recommend version 2.7.2.1 for stability (we've heard both good and bad reports of later versions).
6. The assembler ---a standard UNIX one, probably as .
7. The linker ---a standard UNIX one, probably ld.
8. A runtime system, including (most notably) a storage manager; the linker links in the code for this.
9. The Haskell standard prelude , a large library of standard functions, is linked in as well.
10. Parts of other installed libraries that you have at your site may be linked in also.

1.2 What really happens when I ``compile'' a Haskell program?

You invoke the Glasgow Haskell compilation system through the driver program ghc. For example, if you had typed a literate ``Hello, world!'' program into hello.lhs, and you then invoked:

ghc hello.lhs

the following would happen:

1. The file hello.lhs is run through the literate-program code extractor unlit , feeding its output to
2. The Haskell compiler proper hsc , which produces input for
3. The assembler (or that ubiquitous ``high-level assembler,'' a C compiler), which produces an object file and passes it to
4. The linker, which links your code with the appropriate libraries (including the standard prelude), producing an executable program in the default output file named a.out.

You have considerable control over the compilation process. You feed command-line arguments (call them ``options,'' for short) to the driver, ghc; the ``types'' of the input files (as encoded in their names' suffixes) also matter.

Here's hoping this is enough background so that you can read the rest of this guide!

1.3 Meta-information: Web sites, mailing lists, etc.

On the World-Wide Web, there are several URLs of likely interest:

• Haskell home page
• GHC home page
• Glasgow FP group page
• comp.lang.functional FAQ

We run two mailing lists about Glasgow Haskell. We encourage you to join, as you feel is appropriate.

glasgow-haskell-users:

This list is for GHC users to chat among themselves. Subscribe by sending mail to majordomo@dcs.gla.ac.uk, with a message body (not header) like this:

 
subscribe glasgow-haskell-users MyName <m.y.self@@bigbucks.com> 

(The last bit is your all-important e-mail address, of course.)

To communicate with your fellow users, send mail to glasgow-haskell-users@dcs.gla.ac.uk.

To contact the list administrator, send mail to glasgow-haskell-users-request@dcs.gla.ac.uk. An archive of the list is available on the Web: glasgow-haskell-users mailing list archive.

glasgow-haskell-bugs:

Send bug reports for GHC to this address! The sad and lonely people who subscribe to this list will muse upon what's wrong and what you might do about it.

Subscribe via majordomo@dcs.gla.ac.uk with:

subscribe glasgow-haskell-bugs My Name <m.y.self@@hackers.r.us>

Again, you may contact the list administrator at glasgow-haskell-bugs-request@dcs.gla.ac.uk. And, yes, an archive of the list is available on the Web at: : glasgow-haskell-bugs mailing list archive

There is also the general Haskell mailing list. Subscribe by sending email to majordomo@dcs.gla.ac.uk, with the usual message body:

subscribe haskell My Name <m.y.self@@fp.rules.ok.org>

Some Haskell-related discussion takes place in the Usenet newsgroup comp.lang.functional. (But note: news is basically dead at Glasgow. That's one reason Glaswegians aren't too active in c.f.l.)

The main anonymous-FTP site for Glasgow Haskell is ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow. ``Important'' bits are mirrored at other Haskell archive sites (and we have their stuff, too).

1.4 Release notes for version 4.00---10/98

Language matters

• Universal and existential quantification: see Section Explicit universal quantification and Section Existentially quantified data constructors respectively. Universal quantification was in in GHC 2.10 and later, but the syntax has changed: it's now forall a. ... instead of All a => ....
• Multi-paramter type classes. We have relaxed some of the rules since GHC 3.00. In particular

  -fallow-overlapping-instances

  allows overlapping instances

  -fallow-undecidable-instances

  allows you to write instance contexts that constrain non-type-variables

  Full details in Section Multi-parameter type classes.

New Libraries

Documentation in GHC/Hugs Extension Libraries.

Dynamic

Dynamic types.

Exceptions

The library Exception in -syslib exts provide an interface for exception handling. Calls to error, pattern matching failures and a bunch of other exception can be caught.

Compiler internals

The intermediate language used by GHC has had a radical overhaul. The new Core language (coreSyn/CoreSyn.lhs) is much smaller and more uniform. The main transformation engine (the "simplifier") has been totally rewritten. The compiler is several thousand lines shorter as a result. It's also very much easier to understand and modify. (It's true. Honest!)

Run time system

There is a completely new runtime system, aimed at integration with Hugs. Tons of cruft removed. Some changes to code generation; things typically run a bit faster as a result.

An overview of the new RTS is available: The New GHC/Hugs Runtime System.

Storage Manager/Garbage Collector

The new storage manager features a dynamically resizing heap, so you won't need those pesky -H options anymore. In fact, the -H option is now ignored for compatibility with older versions.

Stacks are now also expandable, and the -K option now specifies a maximum heap size. The default is (a perhaps conservative) 1M.

The garbage collector now collects CAFs, so there's no more space leaks associated with these. If you think you have a CAF-related space leak, we'd like to hear about it.

The storage manager current only has a two-space garbage collector, which will be slower than 3.02's generational collector when the amount of live data is large. A new generational collector is high on our priority list.

For the other new tweakables, see Section RTS options to control the garbage-collector.

Profiling

There is a new profiler based on Cost Centre Stacks. This is an extension of the previous cost centre scheme, whereby the profilier stores information about the call-graph of the program and attributes costs to nodes of this graph.

For a quick demo, try compiling a program with -prof -auto-all, then run it with +RTS -p and see what comes out (in the <prog>.prof file).

The feature is still experimental, and the call graph may not be exactly what you were expecting. Also, we only have time/allocation profiling at the moment; heap profiling will follow shortly.

Miscellaneous

• Concurrent Haskell is now the default. No need to compile/download special libraries. The context switch interval isn't tweakable any more; threads just yield after allocating a fixed amount of heap (currently 4k). If you want a quicker context switch, that won't be possible: this decision was made for efficiency reasons (it reduces the penalty for runnning threaded code to almost zero). We might allow the context switch interval to be increased in the future; but also context switches are pretty fast (faster than before).
• forkIO now returns a ThreadId, and there's a new operation killThread which will terminate an existing thread. See Section The Concurrent interface for more details.
• You need -syslib concurrent to get the Concurrent library.
• The rewritten IO library from 3.03 has been ported to 4.00.
• New constructs: foriegn import and foreign export for H/Direct.
• Supported architectures: all the development has been done on x86(mainly FreeBSD/Linux) so this is the most stable environment. Sparc (Solaris) and x86/Win32 (cygwin32) have also been mildly tested, and an Alpha port is in the works. Everything else will need a little porting effort; we don't have machines here, so any help would be greatly appreciated.
• Code is faster and smaller, but programs might run slower due to the garbage collector (see "Storage Manager" above). Increasing the minimum allocation area with the -A RTS option can claw back some of this speed.
• We now use GMP 2.02, and attempt to use an already-installed copy if available. If you have GMP on your system but the configure script doesn't detect it, we'd like to know.
• The compiler is slightly faster, but sometimes needs more heap. If you have an example where this is the case, please let us know.