Each Haskell source module should be placed in a file on its own.

Usually, the file should be named after the module name, replacing dots in the module name by directory separators. For example, on a Unix system, the module A.B.C should be placed in the file A/B/C.hs, relative to some base directory. If the module is not going to be imported by another module (Main, for example), then you are free to use any filename for it.

GHC assumes that source files are ASCII or UTF-8 only, other encodings are not recognised. However, invalid UTF-8 sequences will be ignored in comments, so it is possible to use other encodings such as Latin-1, as long as the non-comment source code is ASCII only.

When asked to compile a source file, GHC normally generates two files: an object file, and an interface file.

The object file, which normally ends in a .o suffix, contains the compiled code for the module.

The interface file, which normally ends in a .hi suffix, contains the information that GHC needs in order to compile further modules that depend on this module. It contains things like the types of exported functions, definitions of data types, and so on. It is stored in a binary format, so don't try to read one; use the --show-iface option instead (see Section 4.7.7, “Other options related to interface files”).

You should think of the object file and the interface file as a pair, since the interface file is in a sense a compiler-readable description of the contents of the object file. If the interface file and object file get out of sync for any reason, then the compiler may end up making assumptions about the object file that aren't true; trouble will almost certainly follow. For this reason, we recommend keeping object files and interface files in the same place (GHC does this by default, but it is possible to override the defaults as we'll explain shortly).

Every module has a module name defined in its source code (module A.B.C where ...).

The name of the object file generated by GHC is derived according to the following rules, where osuf is the object-file suffix (this can be changed with the -osuf option).

The name of the interface file is derived using the same rules, except that the suffix is hisuf (.hi by default) instead of osuf, and the relevant options are -hidir and -hisuf instead of -odir and -osuf respectively.

For example, if GHC compiles the module A.B.C in the file src/A/B/C.hs, with no -odir or -hidir flags, the interface file will be put in src/A/B/C.hi and the object file in src/A/B/C.o.

For any module that is imported, GHC requires that the name of the module in the import statement exactly matches the name of the module in the interface file (or source file) found using the strategy specified in Section 4.7.3, “The search path”. This means that for most modules, the source file name should match the module name.

However, note that it is reasonable to have a module Main in a file named foo.hs, but this only works because GHC never needs to search for the interface for module Main (because it is never imported). It is therefore possible to have several Main modules in separate source files in the same directory, and GHC will not get confused.

In batch compilation mode, the name of the object file can also be overridden using the -o option, and the name of the interface file can be specified directly using the -ohi option.

In your program, you import a module Foo by saying import Foo. In --make mode or GHCi, GHC will look for a source file for Foo and arrange to compile it first. Without --make, GHC will look for the interface file for Foo, which should have been created by an earlier compilation of Foo. GHC uses the same strategy in each of these cases for finding the appropriate file.

This strategy is as follows: GHC keeps a list of directories called the search path. For each of these directories, it tries appending basename.extension to the directory, and checks whether the file exists. The value of basename is the module name with dots replaced by the directory separator ('/' or '\', depending on the system), and extension is a source extension (hs, lhs) if we are in --make mode or GHCi, or hisuf otherwise.

For example, suppose the search path contains directories d1, d2, and d3, and we are in --make mode looking for the source file for a module A.B.C. GHC will look in d1/A/B/C.hs, d1/A/B/C.lhs, d2/A/B/C.hs, and so on.

The search path by default contains a single directory: “.” (i.e. the current directory). The following options can be used to add to or change the contents of the search path:

This isn't the whole story: GHC also looks for modules in pre-compiled libraries, known as packages. See the section on packages (Section 4.9, “ Packages ”) for details.

The following options are useful for keeping certain intermediate files around, when normally GHC would throw these away after compilation:

In the olden days, GHC compared the newly-generated .hi file with the previous version; if they were identical, it left the old one alone and didn't change its modification date. In consequence, importers of a module with an unchanged output .hi file were not recompiled.

This doesn't work any more. Suppose module C imports module B, and B imports module A. So changes to module A might require module C to be recompiled, and hence when A.hi changes we should check whether C should be recompiled. However, the dependencies of C will only list B.hi, not A.hi, and some changes to A (changing the definition of a function that appears in an inlining of a function exported by B, say) may conceivably not change B.hi one jot. So now…

GHC calculates a fingerprint (in fact an MD5 hash) of each interface file, and of each declaration within the interface file. It also keeps in every interface file a list of the fingerprints of everything it used when it last compiled the file. If the source file's modification date is earlier than the .o file's date (i.e. the source hasn't changed since the file was last compiled), and the recompilation checking is on, GHC will be clever. It compares the fingerprints on the things it needs this time with the fingerprints on the things it needed last time (gleaned from the interface file of the module being compiled); if they are all the same it stops compiling early in the process saying “Compilation IS NOT required”. What a beautiful sight!

You can read about how all this works in the GHC commentary.

GHC supports the compilation of mutually recursive modules. This section explains how.

Every cycle in the module import graph must be broken by a hs-boot file. Suppose that modules A.hs and B.hs are Haskell source files, thus:

module A where
    import B( TB(..) )

    newtype TA = MkTA Int

    f :: TB -> TA
    f (MkTB x) = MkTA x

module B where
    import {-# SOURCE #-} A( TA(..) )

    data TB = MkTB !Int

    g :: TA -> TB
    g (MkTA x) = MkTB x

Here A imports B, but B imports A with a {-# SOURCE #-} pragma, which breaks the circular dependency. Every loop in the module import graph must be broken by a {-# SOURCE #-} import; or, equivalently, the module import graph must be acyclic if {-# SOURCE #-} imports are ignored.

For every module A.hs that is {-# SOURCE #-}-imported in this way there must exist a source file A.hs-boot. This file contains an abbreviated version of A.hs, thus:

module A where
    newtype TA = MkTA Int

To compile these three files, issue the following commands:

  ghc -c A.hs-boot    -- Produces A.hi-boot, A.o-boot
  ghc -c B.hs         -- Consumes A.hi-boot, produces B.hi, B.o
  ghc -c A.hs	      -- Consumes B.hi, produces A.hi, A.o
  ghc -o foo A.o B.o  -- Linking the program

There are several points to note here:

A hs-boot file need only contain the bare minimum of information needed to get the bootstrapping process started. For example, it doesn't need to contain declarations for everything that module A exports, only the things required by the module(s) that import A recursively.

A hs-boot file is written in a subset of Haskell:

It is reasonably straightforward to set up a Makefile to use with GHC, assuming you name your source files the same as your modules. Thus:

HC      = ghc
HC_OPTS = -cpp $(EXTRA_HC_OPTS)

SRCS = Main.lhs Foo.lhs Bar.lhs
OBJS = Main.o   Foo.o   Bar.o

.SUFFIXES : .o .hs .hi .lhs .hc .s

cool_pgm : $(OBJS)
        rm -f $@
        $(HC) -o $@ $(HC_OPTS) $(OBJS)

# Standard suffix rules
.o.hi:
        @:

.lhs.o:
        $(HC) -c $< $(HC_OPTS)

.hs.o:
        $(HC) -c $< $(HC_OPTS)

.o-boot.hi-boot:
        @:

.lhs-boot.o-boot:
        $(HC) -c $< $(HC_OPTS)

.hs-boot.o-boot:
        $(HC) -c $< $(HC_OPTS)

# Inter-module dependencies
Foo.o Foo.hc Foo.s    : Baz.hi          # Foo imports Baz
Main.o Main.hc Main.s : Foo.hi Baz.hi   # Main imports Foo and Baz

(Sophisticated make variants may achieve some of the above more elegantly. Notably, gmake's pattern rules let you write the more comprehensible:

%.o : %.lhs
        $(HC) -c $< $(HC_OPTS)

What we've shown should work with any make.)

Note the cheesy .o.hi rule: It records the dependency of the interface (.hi) file on the source. The rule says a .hi file can be made from a .o file by doing…nothing. Which is true.

Note that the suffix rules are all repeated twice, once for normal Haskell source files, and once for hs-boot files (see Section 4.7.9, “How to compile mutually recursive modules”).

Note also the inter-module dependencies at the end of the Makefile, which take the form

Foo.o Foo.hc Foo.s    : Baz.hi          # Foo imports Baz

They tell make that if any of Foo.o, Foo.hc or Foo.s have an earlier modification date than Baz.hi, then the out-of-date file must be brought up to date. To bring it up to date, make looks for a rule to do so; one of the preceding suffix rules does the job nicely. These dependencies can be generated automatically by ghc; see Section 4.7.11, “Dependency generation”

Putting inter-dependencies of the form Foo.o : Bar.hi into your Makefile by hand is rather error-prone. Don't worry, GHC has support for automatically generating the required dependencies. Add the following to your Makefile:

depend :
        ghc -M $(HC_OPTS) $(SRCS)

Now, before you start compiling, and any time you change the imports in your program, do make depend before you do make cool_pgm. The command ghc -M will append the needed dependencies to your Makefile.

In general, ghc -M Foo does the following. For each module M in the set Foo plus all its imports (transitively), it adds to the Makefile:

If M imports multiple modules, then there will be multiple lines with M.o as the target.

There is no need to list all of the source files as arguments to the ghc -M command; ghc traces the dependencies, just like ghc --make (a new feature in GHC 6.4).

Note that ghc -M needs to find a source file for each module in the dependency graph, so that it can parse the import declarations and follow dependencies. Any pre-compiled modules without source files must therefore belong to a package^[7].

By default, ghc -M generates all the dependencies, and then concatenates them onto the end of makefile (or Makefile if makefile doesn't exist) bracketed by the lines "# DO NOT DELETE: Beginning of Haskell dependencies" and "# DO NOT DELETE: End of Haskell dependencies". If these lines already exist in the makefile, then the old dependencies are deleted first.

Don't forget to use the same -package options on the ghc -M command line as you would when compiling; this enables the dependency generator to locate any imported modules that come from packages. The package modules won't be included in the dependencies generated, though (but see the ––include-pkg-deps option below).

The dependency generation phase of GHC can take some additional options, which you may find useful. The options which affect dependency generation are:

Haskell specifies that when compiling module M, any instance declaration in any module "below" M is visible. (Module A is "below" M if A is imported directly by M, or if A is below a module that M imports directly.) In principle, GHC must therefore read the interface files of every module below M, just in case they contain an instance declaration that matters to M. This would be a disaster in practice, so GHC tries to be clever.

In particular, if an instance declaration is in the same module as the definition of any type or class mentioned in the head of the instance declaration (the part after the “=>”; see Section 7.6.3.2, “Relaxed rules for instance contexts”), then GHC has to visit that interface file anyway. Example:

  module A where
    instance C a => D (T a) where ...
    data T a = ...

The instance declaration is only relevant if the type T is in use, and if so, GHC will have visited A's interface file to find T's definition.

The only problem comes when a module contains an instance declaration and GHC has no other reason for visiting the module. Example:

  module Orphan where
    instance C a => D (T a) where ...
    class C a where ...

Here, neither D nor T is declared in module Orphan. We call such modules “orphan modules”. GHC identifies orphan modules, and visits the interface file of every orphan module below the module being compiled. This is usually wasted work, but there is no avoiding it. You should therefore do your best to have as few orphan modules as possible.

Functional dependencies complicate matters. Suppose we have:

  module B where
    instance E T Int where ...
    data T = ...

Is this an orphan module? Apparently not, because T is declared in the same module. But suppose class E had a functional dependency:

  module Lib where
    class E x y | y -> x where ...

Then in some importing module M, the constraint (E a Int) should be "improved" by setting a = T, even though there is no explicit mention of T in M.

If you use the flag -fwarn-orphans, GHC will warn you if you are creating an orphan module. Like any warning, you can switch the warning off with -fno-warn-orphans, and -Werror will make the compilation fail if the warning is issued.

You can identify an orphan module by looking in its interface file, M.hi, using the --show-iface mode. If there is a [orphan module] on the first line, GHC considers it an orphan module.