This section describes what files GHC expects to find, what files it creates, where these files are stored, and what options affect this behaviour.
Pathname conventions vary from system to system. In particular, the directory separator is “/
” on Unix systems and “\
” on Windows systems. In the sections that follow, we shall consistently use “/
” as the directory separator; substitute this for the appropriate character for your system.
5.8.1. Haskell source files
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 encoding 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.
5.8.2. Output files
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 ⟨file⟩
option instead (see 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).
- If there is no
-odir
option (the default), then the object filename is derived from the source filename (ignoring the module name) by replacing the suffix with ⟨osuf⟩. - If
-odir ⟨dir⟩
has been specified, then the object filename is ⟨dir⟩/⟨mod⟩.⟨osuf⟩, where ⟨mod⟩ is the module name with dots replaced by slashes. GHC will silently create the necessary directory structure underneath ⟨dir⟩, if it does not already exist.
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 ⟨dir⟩
and -hisuf ⟨suffix⟩
instead of -odir ⟨dir⟩
and -osuf ⟨suffix⟩
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 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 ⟨file⟩
option, and the name of the interface file can be specified directly using the -ohi ⟨file⟩
option.
5.8.3. The search path
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
.
The strategy for looking for source files 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.
When looking for interface files in -c
mode, we look for interface files in the -hidir
, if it’s set. Otherwise the same strategy as for source files is used to try to locate the interface file.
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:
-i⟨dir⟩[:⟨dir⟩]*
-
This flag appends a colon-separated list of
dirs
to the search path.
-i
-
resets the search path back to nothing.
This isn’t the whole story: GHC also looks for modules in pre-compiled libraries, known as packages. See the section on packages (Packages) for details.
5.8.4. Redirecting the compilation output(s)
-o ⟨file⟩
-
GHC’s compiled output normally goes into a
.hc
,.o
, etc., file, depending on the last-run compilation phase. The option-o file
re-directs the output of that last-run phase to ⟨file⟩.Note
This “feature” can be counterintuitive:
ghc -C -o foo.o foo.hs
will put the intermediate C code in the filefoo.o
, name notwithstanding!This option is most often used when creating an executable file, to set the filename of the executable. For example:
ghc -o prog --make Main
will compile the program starting with module
Main
and put the executable in the fileprog
.Note: on Windows, if the result is an executable file, the extension “
.exe
” is added if the specified filename does not already have an extension. Thusghc -o foo Main.hs
will compile and link the module
Main.hs
, and put the resulting executable infoo.exe
(notfoo
).If you use
ghc --make
and you don’t use the-o
, the name GHC will choose for the executable will be based on the name of the file containing the moduleMain
. Note that with GHC theMain
module doesn’t have to be put in fileMain.hs
. Thus bothghc --make Prog
and
ghc --make Prog.hs
will produce
Prog
(orProg.exe
if you are on Windows).
-dyno ⟨file⟩
-
When using
-dynamic-too
, option-dyno
⟨suffix⟩ is the counterpart of-o
. It redirects the dynamic output to ⟨file⟩.
-odir ⟨dir⟩
-
Redirects object files to directory ⟨dir⟩. For example:
$ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `uname -m`
The object files,
Foo.o
,Bar.o
, andBumble.o
would be put into a subdirectory named after the architecture of the executing machine (x86
,mips
, etc).Note that the
-odir
option does not affect where the interface files are put; use the-hidir
option for that. In the above example, they would still be put inparse/Foo.hi
,parse/Bar.hi
, andgurgle/Bumble.hi
.Please also note that when doing incremental compilation, this directory is where GHC looks into to find object files from previous builds.
-ohi ⟨file⟩
-
The interface output may be directed to another file
bar2/Wurble.iface
with the option-ohi bar2/Wurble.iface
(not recommended).Warning
If you redirect the interface file somewhere that GHC can’t find it, then the recompilation checker may get confused (at the least, you won’t get any recompilation avoidance). We recommend using a combination of
-hidir
and-hisuf
options instead, if possible.To avoid generating an interface at all, you could use this option to redirect the interface into the bit bucket:
-ohi /dev/null
, for example.
-dynohi ⟨file⟩
-
When using
-dynamic-too
, option-dynohi
⟨file⟩ is the counterpart of-ohi
. It redirects the dynamic interface output to ⟨file⟩.
-hidir ⟨dir⟩
-
Redirects all generated interface files into ⟨dir⟩, instead of the default.
Please also note that when doing incremental compilation (by
ghc --make
orghc -c
), this directory is where GHC looks into to find interface files.
-hiedir ⟨dir⟩
-
Redirects all generated extended interface files into ⟨dir⟩, instead of the default.
Please also note that when doing incremental compilation (by
ghc --make
orghc -c
), this directory is where GHC looks into to find extended interface files.
-stubdir ⟨dir⟩
-
Redirects all generated FFI stub files into ⟨dir⟩. Stub files are generated when the Haskell source contains a
foreign export
orforeign import "&wrapper"
declaration (see Using foreign export and foreign import ccall "wrapper" with GHC). The-stubdir
option behaves in exactly the same way as-odir
and-hidir
with respect to hierarchical modules.
-dumpdir ⟨dir⟩
-
Redirects all dump files into ⟨dir⟩. Dump files are generated when
-ddump-to-file
is used with other-ddump-*
flags.
-outputdir ⟨dir⟩
-
The
-outputdir
option is shorthand for the combination of-odir ⟨dir⟩
,-hidir ⟨dir⟩
,-hiedir ⟨dir⟩
,-stubdir ⟨dir⟩
and-dumpdir ⟨dir⟩
.
-osuf ⟨suffix⟩
-
The
-osuf
⟨suffix⟩ will change the.o
file suffix for object files to whatever you specify. We use this when compiling libraries, so that objects for the profiling versions of the libraries don’t clobber the normal ones.
-dynosuf ⟨suffix⟩
-
When using
-dynamic-too
, option-dynosuf
⟨suffix⟩ is the counterpart of-osuf
. It changes the.dyn_o
file suffix for dynamic object files.
-hisuf ⟨suffix⟩
-
Similarly, the
-hisuf
⟨suffix⟩ will change the.hi
file suffix for non-system interface files (see Other options related to interface files).The
-hisuf
/-osuf
game is particularly useful if you want to compile a program both with and without profiling, in the same directory. You can say:ghc ...
to get the ordinary version, and
ghc ... -osuf prof.o -hisuf prof.hi -prof -fprof-auto
to get the profiled version.
-dynhisuf ⟨suffix⟩
-
When using
-dynamic-too
, option-dynhisuf
⟨suffix⟩ is the counterpart of-hisuf
. It changes the.dyn_hi
file suffix for dynamic interface files.
-hiesuf ⟨suffix⟩
-
The
-hiesuf
⟨suffix⟩ will change the.hie
file suffix for extended interface files to whatever you specify.
-hcsuf ⟨suffix⟩
-
Finally, the option
-hcsuf
⟨suffix⟩ will change the.hc
file suffix for compiler-generated intermediate C files.
5.8.5. Keeping Intermediate Files
The following options are useful for keeping (or not keeping) certain intermediate files around, when normally GHC would throw these away after compilation:
-keep-hc-file
-keep-hc-files
-
Keep intermediate
.hc
files when doing.hs
-to-.o
compilations via C (Note:.hc
files are only generated by unregisterised compilers).
-keep-hi-files
-
Keep intermediate
.hi
files. This is the default. You may use-no-keep-hi-files
if you are not interested in the.hi
files.
-keep-hscpp-file
-keep-hscpp-files
-
Keep the output of the
CPP
pre-processor phase as.hscpp
files. A.hscpp
file is only created, if a module gets compiled and uses the C pre-processor.
-keep-llvm-file
-keep-llvm-files
-
Implies: -fllvm
Keep intermediate
.ll
files when doing.hs
-to-.o
compilations via LLVM (Note:.ll
files aren’t generated when using the native code generator, you may need to use-fllvm
to force them to be produced).
-keep-o-files
-
Keep intermediate
.o
files. This is the default. You may use-no-keep-o-files
if you are not interested in the.o
files.
-keep-s-file
-keep-s-files
-
Keep intermediate
.s
files.
-keep-tmp-files
-
Instructs the GHC driver not to delete any of its temporary files, which it normally keeps in
/tmp
(or possibly elsewhere; see Redirecting temporary files). Running GHC with-v
will show you what temporary files were generated along the way.
5.8.6. Redirecting temporary files
-tmpdir ⟨dir⟩
-
If you have trouble because of running out of space in
/tmp
(or wherever your installation thinks temporary files should go), you may use the-tmpdir ⟨dir⟩
option to specify an alternate directory. For example,-tmpdir .
says to put temporary files in the current working directory.Alternatively, use your
TMPDIR
environment variable. Set it to the name of the directory where temporary files should be put. GCC and other programs will honour theTMPDIR
variable as well.
5.8.7. Other options related to interface files
-ddump-hi-diffs
-
The compiler does not overwrite an existing
.hi
interface file if the new one is the same as the old one; this is friendly to make. When an interface does change, it is often enlightening to be informed. The-ddump-hi-diffs
option will make GHC report the differences between the old and new.hi
files.
-ddump-minimal-imports
-
Dump to the file
M.imports
(where ⟨M⟩ is the name of the module being compiled) a “minimal” set of import declarations. The directory where the.imports
files are created can be controlled via the-dumpdir ⟨dir⟩
option.You can safely replace all the import declarations in
M.hs
with those found in its respective.imports
file. Why would you want to do that? Because the “minimal” imports (a) import everything explicitly, by name, and (b) import nothing that is not required. It can be quite painful to maintain this property by hand, so this flag is intended to reduce the labour.
--show-iface ⟨file⟩
-
where ⟨file⟩ is the name of an interface file, dumps the contents of that interface in a human-readable format. See Modes of operation.
5.8.8. Options related to extended interface files
a simplified AST
- nodes are annotated with source positions and types
- identifiers are annotated with scope information
- the raw bytes of the initial Haskell source
The GHC API exposes functions for reading and writing these files.
-fwrite-ide-info
-
Writes out extended interface files alongside regular interface files. Just like regular interface files, GHC has a recompilation check to detect out of date or missing extended interface files.
-fvalidate-ide-info
-
Runs a series of sanity checks and lints on the extended interface files that are being written out. These include testing things properties such as variables not occurring outside of their expected scopes.
The format in which GHC currently stores its typechecked AST, makes it costly to collect the types for some expressions nodes. For the sake of performance, GHC currently chooses to skip over these, so not all expression nodes should be expected to have type information on them. See #16233 for more.
5.8.9. The recompilation checker
-fforce-recomp
-
Turn off recompilation checking (which is on by default). Recompilation checking normally stops compilation early, leaving an existing
.o
file in place, if it can be determined that the module does not need to be recompiled.
-fignore-optim-changes
-fignore-hpc-changes
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 MD5 hash of the source file stored in the .hi
file hasn’t changed, the .o
file’s modification date is greater than or equal to that of the .hi
file, 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.
5.8.9.1. Recompilation for Template Haskell and Plugins
Recompilation checking gets a bit more complicated when using Template Haskell or plugins. Both these features execute code at compile time and so if any of the executed code changes then it’s necessary to recompile the module. Consider the top-level splice:
main = $(foo bar [| () |])
When the module is compiled foo bar [| () |]
will be evaluated and the resulting code placed into the program. The dependencies of the expression are calculated and stored during module compilation. When the interface file is written, additional dependencies are created on the object file dependencies of the expression. For instance, if foo
is from module A
and bar
is from module B
, the module will now depend on A.o
and B.o
, if either of these change then the module will be recompiled.
5.8.10. How to compile mutually recursive modules
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:
- The file
A.hs-boot
is a programmer-written source file. It must live in the same directory as its parent source fileA.hs
. Currently, if you use a literate source fileA.lhs
you must also use a literate boot file,A.lhs-boot
; and vice versa. A
hs-boot
file is compiled by GHC, just like ahs
file:ghc -c A.hs-boot
When a hs-boot file
A.hs-boot
is compiled, it is checked for scope and type errors. When its parent moduleA.hs
is compiled, the two are compared, and an error is reported if the two are inconsistent.Just as compiling
A.hs
produces an interface fileA.hi
, and an object fileA.o
, so compilingA.hs-boot
produces an interface fileA.hi-boot
, and a pseudo-object fileA.o-boot
:- The pseudo-object file
A.o-boot
is empty (don’t link it!), but it is very useful when using a Makefile, to record when theA.hi-boot
was last brought up to date (see Using make). - The
hi-boot
generated by compiling ahs-boot
file is in the same machine-generated binary format as any other GHC-generated interface file (e.g.B.hi
). You can display its contents withghc --show-iface
. If you specify a directory for interface files, the-hidir
flag, then that affectshi-boot
files too.
- The pseudo-object file
- If hs-boot files are considered distinct from their parent source files, and if a
{-# SOURCE #-}
import is considered to refer to the hs-boot file, then the module import graph must have no cycles. The commandghc -M
will report an error if a cycle is found. - A module
M
that is{-# SOURCE #-}
-imported in a program will usually also be ordinarily imported elsewhere. If not,ghc --make
automatically addsM
to the set of modules it tries to compile and link, to ensure thatM
’s implementation is included in the final program.
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:
- The module header (including the export list), and import statements, are exactly as in Haskell, and so are the scoping rules. Hence, to mention a non-Prelude type or class, you must import it.
There must be no value declarations, but there can be type signatures for values. For example:
double :: Int -> Int
- Fixity declarations are exactly as in Haskell.
- Vanilla type synonym declarations are exactly as in Haskell.
- Open type and data family declarations are exactly as in Haskell.
A closed type family may optionally omit its equations, as in the following example:
type family ClosedFam a where ..
The
..
is meant literally – you should write two dots in your file. Note that thewhere
clause is still necessary to distinguish closed families from open ones. If you give any equations of a closed family, you must give all of them, in the same order as they appear in the accompanying Haskell file.A data type declaration can either be given in full, exactly as in Haskell, or it can be given abstractly, by omitting the ‘=’ sign and everything that follows. For example:
data T a b
In a source program this would declare TA to have no constructors (a GHC extension: see Data types with no constructors), but in an hi-boot file it means “I don’t know or care what the constructors are”. This is the most common form of data type declaration, because it’s easy to get right. You can also write out the constructors but, if you do so, you must write it out precisely as in its real definition.
If you do not write out the constructors, you may need to give a kind annotation (Explicitly-kinded quantification), to tell GHC the kind of the type variable, if it is not “*”. (In source files, this is worked out from the way the type variable is used in the constructors.) For example:
data R (x :: * -> *) y
You cannot use
deriving
on a data type declaration; write aninstance
declaration instead.Class declarations can either be given in full, exactly as in Haskell, or they can be given abstractly by omitting everything other than the instance head: no superclasses, no class methods, no associated types. However, if the class has any ::extension::
FunctionalDependencies
, those given in the hs-boot file must be the same.If the class declaration is given in full, the entire class declaration must be identical, up to a renaming of the type variables bound by the class head. This means:
- The class head must be the same.
- The class context must be the same, up to simplification of constraints.
- If there are any ::extension::
FunctionalDependencies
, these must be the same. - The order, names, and types of the class methods must be the same.
- The arity and kinds of any associated types must be the same.
- Default methods as well as default signatures (see ::extension::
DefaultSignatures
) must be provided for the same methods, and must be the same. - Default declarations for associated types must be provided for the same types, and must be the same.
To declare a class with no methods in an hs-boot file, it must have a superclass. If the class has no superclass constraints, add an empty one, e.g.
class () => C a
This is a full class declaration, not an abstract declaration in which the methods were omitted.
- You can include instance declarations just as in Haskell; but omit the “where” part.
- The default role for abstract datatype parameters is now representational. (An abstract datatype is one with no constructors listed.) To get another role, use a role annotation. (See Roles.)
5.8.11. Module signatures
GHC 8.2 supports module signatures (hsig
files), which allow you to write a signature in place of a module implementation, deferring the choice of implementation until a later point in time. This feature is not intended to be used without Cabal; this manual entry will focus on the syntax and semantics of signatures.
To start with an example, suppose you had a module A
which made use of some string operations. Using normal module imports, you would only be able to pick a particular implementation of strings:
module Str where
type Str = String
empty :: Str
empty = ""
toString :: Str -> String
toString s = s
module A where
import Str
z = toString empty
By replacing Str.hs
with a signature Str.hsig
, A
(and any other modules in this package) are now parametrized by a string implementation:
signature Str where
data Str
empty :: Str
toString :: Str -> String
We can typecheck A
against this signature, or we can instantiate Str
with a module that provides the following declarations. Refer to Cabal’s documentation for a more in-depth discussion on how to instantiate signatures.
Module signatures actually consist of two closely related features:
- The ability to define an
hsig
file, containing type definitions and type signature for values which can be used by modules that import the signature, and must be provided by the eventual implementing module, and - The ability to inherit required signatures from packages we depend upon, combining the signatures into a single merged signature which reflects the requirements of any locally defined signature, as well as the requirements of our dependencies.
A signature file is denoted by an hsig
file; every required signature must have an hsig
file (even if it is an empty one), including required signatures inherited from dependencies. Signatures can be imported using an ordinary import Sig
declaration.
hsig
files are written in a variant of Haskell similar to hs-boot
files, but with some slight changes:
- The header of a signature is
signature A where ...
(instead of the usualmodule A where ...
). - Import statements and scoping rules are exactly as in Haskell. To mention a non-Prelude type or class, you must import it.
Unlike regular modules, the defined entities of a signature include not only those written in the local
hsig
file, but also those from inherited signatures (as inferred from the-package-id ⟨unit-id⟩
flags). These entities are not considered in scope when typechecking the localhsig
file, but are available for import by any module or signature which imports the signature. The one exception to this rule is the export list, described below.If a declaration occurs in multiple inherited signatures, they will be merged together. For values, we require that the types from both signatures match exactly; however, other declarations may merge in more interesting ways. The merging operation in these cases has the effect of textually replacing all occurrences of the old name with a reference to the new, merged declaration. For example, if we have the following two signatures:
signature A where data T f :: T -> T signature A where data T = MkT g :: T
the resulting merged signature would be:
signature A where data T = MkT f :: T -> T g :: T
If no export list is provided for a signature, the exports of a signature are all of its defined entities merged with the exports of all inherited signatures.
If you want to reexport an entity from a signature, you must also include a
module SigName
export, so that all of the entities defined in the signature are exported. For example, the following module exports bothf
andInt
fromPrelude
:signature A(module A, Int) where import Prelude (Int) f :: Int
Reexports merge with local declarations; thus, the signature above would successfully merge with:
signature A where data Int
The only permissible implementation of such a signature is a module which reexports precisely the same entity:
module A (f, Int) where import Prelude (Int) f = 2 :: Int
Conversely, any entity requested by a signature can be provided by a reexport from the implementing module. This is different from
hs-boot
files, which require every entity to be defined locally in the implementing module.GHC has experimental support for signature thinning, which is used when a signature has an explicit export list without a module export of the signature itself. In this case, the export list applies to the final export list after merging, in particular, you may refer to entities which are not declared in the body of the local
hsig
file.The semantics in this case is that the set of required entities is defined exclusively by its exports; if an entity is not mentioned in the export list, it is not required. The motivation behind this feature is to allow a library author to provide an omnibus signature containing the type of every function someone might want to use, while a client thins down the exports to the ones they actually require. For example, supposing that you have inherited a signature for strings, you might write a local signature of this form, listing only the entities that you need:
signature Str (Str, empty, append, concat) where -- empty
A few caveats apply here. First, it is illegal to export an entity which refers to a locally defined type which itself is not exported (GHC will report an error in this case). Second, signatures which come from dependencies which expose modules cannot be thinned in this way (after all, the dependency itself may need the entity); these requirements are unconditionally exported. Finally, any module reexports must refer to modules imported by the local signature (even if an inherited signature exported the module).
We may change the syntax and semantics of this feature in the future.
The declarations and types from signatures of dependencies that will be merged in are not in scope when type checking an
hsig
file. To refer to any such type, you must declare it yourself:-- OK, assuming we inherited an A that defines T signature A (T) where -- empty -- Not OK signature A (T, f) where f :: T -> T -- OK signature A (T, f) where data T f :: T -> T
There must be no value declarations, but there can be type signatures for values. For example, we might define the signature:
signature A where double :: Int -> Int
A module implementing
A
would have to export the functiondouble
with a type definitionally equal to the signature. Note that this means you can’t implementdouble
using a polymorphic functiondouble :: Num a => a -> a
.Note that signature matching does check if fixity matches, so be sure specify fixity of ordinary identifiers if you intend to use them with backticks.
- Fixity, type synonym, open type/data family declarations are permitted as in normal Haskell.
Closed type family declarations are permitted as in normal Haskell. They can also be given abstractly, as in the following example:
type family ClosedFam a where ..
The
..
is meant literally – you should write two dots in your file. Thewhere
clause distinguishes closed families from open ones.A data type declaration can either be given in full, exactly as in Haskell, or it can be given abstractly, by omitting the ‘=’ sign and everything that follows. For example:
signature A where data T a b
Abstract data types can be implemented not only with data declarations, but also newtypes and type synonyms (with the restriction that a type synonym must be fully eta-reduced, e.g.,
type T = ...
to be accepted.) For example, the following are all valid implementations of the T above:-- Algebraic data type data T a b = MkT a b -- Newtype newtype T a b = MkT (a, b) -- Type synonym data T2 a b = MkT2 a a b b type T = T2
Data type declarations merge only with other data type declarations which match exactly, except abstract data, which can merge with
data
,newtype
ortype
declarations. Merges with type synonyms are especially useful: suppose you are using a package of strings which has left the type of characters in the string unspecified:signature Str where data Str data Elem head :: Str -> Elem
If you locally define a signature which specifies
type Elem = Char
, you can now usehead
from the inherited signature as if it returned aChar
.If you do not write out the constructors, you may need to give a kind to tell GHC what the kinds of the type variables are, if they are not the default
*
. Unlike regular data type declarations, the return kind of an abstract data declaration can be anything (in which case it probably will be implemented using a type synonym.) This can be used to allow compile-time representation polymorphism (as opposed to run-time representation polymorphism), as in this example:signature Number where import GHC.Types data Rep :: RuntimeRep data Number :: TYPE Rep plus :: Number -> Number -> Number
Roles of type parameters are subject to the subtyping relation
phantom < representational < nominal
: for example, an abstract type with a nominal type parameter can be implemented using a concrete type with a representational type parameter. Merging respects this subtyping relation (e.g.,nominal
merged withrepresentational
isrepresentational
.) Roles in signatures default tonominal
, which gives maximum flexibility on the implementor’s side. You should only need to give an explicit role annotation if a client of the signature would like to coerce the abstract type in a type parameter (in which case you should specifyrepresentational
explicitly.) Unlike regular data types, we do not assume that abstract data types are representationally injective: if we haveCoercible (T a) (T b)
, andT
has rolenominal
, this does not imply thata ~ b
.A class declarations can either be abstract or concrete. An abstract class is one with no superclasses or class methods:
signature A where class Key k
It can be implemented in any way, with any set of superclasses and methods; however, modules depending on an abstract class are not permitted to define instances (as of GHC 8.2, this restriction is not checked, see #13086.) These declarations can be implemented by type synonyms of kind
Constraint
; this can be useful if you want to parametrize over a constraint in functions. For example, with theConstraintKinds
extension, this type synonym is a valid implementation of the signature above:module A where type Key = Eq
A concrete class specifies its superclasses, methods, default method signatures (but not their implementations) and a
MINIMAL
pragma. Unlike regular Haskell classes, you don’t have to explicitly declare a default for a method to make it optional vis-a-vis theMINIMAL
pragma.When merging class declarations, we require that the superclasses and methods match exactly; however,
MINIMAL
pragmas are logically ORed together, and a method with a default signature will merge successfully against one that does not.You can include instance declarations as in Haskell; just omit the “where” part. An instance declaration need not be implemented directly; if an instance can be derived based on instances in the environment, it is considered implemented. For example, the following signature:
signature A where data Str instance Eq Str
is considered implemented by the following module, since there are instances of
Eq
for[]
andChar
which can be combined to form an instanceEq [Char]
:module A where type Str = [Char]
Unlike other declarations, for which only the entities declared in a signature file are brought into scope, instances from the implementation are always brought into scope, even if they were not declared in the signature file. This means that a module may typecheck against a signature, but not against a matching implementation. You can avoid situations like this by never defining orphan instances inside a package that has signatures.
Instance declarations are only merged if their heads are exactly the same, so it is possible to get into a situation where GHC thinks that instances in a signature are overlapping, even if they are implemented in a non-overlapping way. If this is giving you problems give us a shout.
- Any orphan instances which are brought into scope by an import from a signature are unconditionally considered in scope, even if the eventual implementing module doesn’t actually import the same orphans.
Known limitations:
- Pattern synonyms are not supported.
- Algebraic data types specified in a signature cannot be implemented using pattern synonyms. See #12717
5.8.12. Using make
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
Note
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 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 Dependency generation
5.8.13. 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:
A line recording the dependence of the object file on the source file.
M.o : M.hs
(or
M.lhs
if that is the filename you used).For each import declaration
import X
inM
, a line recording the dependence ofM
onX
:M.o : X.hi
For each import declaration
import {-# SOURCE #-} X
inM
, a line recording the dependence ofM
onX
:M.o : X.hi-boot
(See How to compile mutually recursive modules for details of
hi-boot
style interface files.)
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 [1].
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:
-ddump-mod-cycles
-
Display a list of the cycles in the module graph. This is useful when trying to eliminate such cycles.
-v2
-
Print a full list of the module dependencies to stdout. (This is the standard verbosity flag, so the list will also be displayed with
-v3
and-v4
; see Verbosity options.)
-dep-makefile ⟨file⟩
-
Use ⟨file⟩ as the makefile, rather than
makefile
orMakefile
. If ⟨file⟩ doesn’t exist,mkdependHS
creates it. We often use-dep-makefile .depend
to put the dependencies in.depend
and theninclude
the file.depend
intoMakefile
.
-dep-suffix ⟨suffix⟩
-
Make dependencies that declare that files with suffix
.⟨suf⟩⟨osuf⟩
depend on interface files with suffix.⟨suf⟩hi
, or (for{-# SOURCE #-}
imports) on.hi-boot
. Multiple-dep-suffix
flags are permitted. For example,-dep-suffix a_ -dep-suffix b_
will make dependencies for.hs
on.hi
,.a_hs
on.a_hi
, and.b_hs
on.b_hi
. If you do not use this flag then the empty suffix is used.
--exclude-module=⟨file⟩
-
Regard
⟨file⟩
as “stable”; i.e., exclude it from having dependencies on it.
-include-pkg-deps
-
Regard modules imported from packages as unstable, i.e., generate dependencies on any imported package modules (including
Prelude
, and all other standard Haskell libraries). Dependencies are not traced recursively into packages; dependencies are only generated for home-package modules on external-package modules directly imported by the home package module. This option is normally only used by the various system libraries.
-include-cpp-deps
-
Output preprocessor dependencies. This only has an effect when the CPP language extension is enabled. These dependencies are files included with the
#include
preprocessor directive (as well as transitive includes) and implicitly included files such as standard c preprocessor headers and a GHC version header. One exception to this is that GHC generates a temporary header file (during compilation) containing package version macros. As this is only a temporary file that GHC will always generate, it is not output as a dependency.
5.8.14. Orphan modules and instance declarations
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 Instance termination rules), 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
.
These considerations lead to the following definition of an orphan module:
- An orphan module orphan module contains at least one orphan instance or at least one orphan rule.
An instance declaration in a module
M
is an orphan instance if- The class of the instance declaration is not declared in
M
, and - Either the class has no functional dependencies, and none of the type constructors in the instance head is declared in
M
; or there is a functional dependency for which none of the type constructors mentioned in the non-determined part of the instance head is defined inM
.
Only the instance head counts. In the example above, it is not good enough for
C
’s declaration to be in moduleA
; it must be the declaration ofD
orT
.- The class of the instance declaration is not declared in
- A rewrite rule in a module
M
is an orphan rule orphan rule if none of the variables, type constructors, or classes that are free in the left hand side of the rule are declared inM
.
If you use the flag -Worphans
, GHC will warn you if you are creating an orphan module. Like any warning, you can switch the warning off with -Wno-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 ⟨file⟩
mode. If there is a [orphan module]
on the first line, GHC considers it an orphan module.
[1] | This is a change in behaviour relative to 6.2 and earlier. |