ghc/docs/users_guide/separate_compilation.xml

   1 <?xml version="1.0" encoding="iso-8859-1"?>
   2   <sect1 id="separate-compilation">
   3     <title>Filenames and separate compilation</title>
   4
   5     <indexterm><primary>separate compilation</primary></indexterm>
   6     <indexterm><primary>recompilation checker</primary></indexterm>
   7     <indexterm><primary>make and recompilation</primary></indexterm>
   8
   9     <para>This section describes what files GHC expects to find, what
  10     files it creates, where these files are stored, and what options
  11     affect this behaviour.</para>
  12
  13     <para>Note that this section is written with
  14     <firstterm>hierarchical modules</firstterm> in mind (see <xref
  15     linkend="hierarchical-modules"/>); hierarchical modules are an
  16     extension to Haskell 98 which extends the lexical syntax of
  17     module names to include a dot &lsquo;.&rsquo;.  Non-hierarchical
  18     modules are thus a special case in which none of the module names
  19     contain dots.</para>
  20
  21     <para>Pathname conventions vary from system to system.  In
  22     particular, the directory separator is
  23     &lsquo;<literal>/</literal>&rsquo; on Unix systems and
  24     &lsquo;<literal>\</literal>&rsquo; on Windows systems.  In the
  25     sections that follow, we shall consistently use
  26     &lsquo;<literal>/</literal>&rsquo; as the directory separator;
  27     substitute this for the appropriate character for your
  28     system.</para>
  29
  30     <sect2 id="source-files">
  31       <title>Haskell source files</title>
  32
  33       <para>Each Haskell source module should be placed in a file on
  34       its own.</para>
  35
  36       <para>The file should usually be named after the module name, by
  37       replacing dots in the module name by directory separators.  For
  38       example, on a Unix system, the module <literal>A.B.C</literal>
  39       should be placed in the file <literal>A/B/C.hs</literal>,
  40       relative to some base directory.  GHC's behaviour if this rule
  41       is not followed is fully defined by the following section (<xref
  42       linkend="output-files"/>).</para>
  43     </sect2>
  44
  45     <sect2 id="output-files">
  46       <title>Output files</title>
  47
  48       <indexterm><primary>interface files</primary></indexterm>
  49       <indexterm><primary><literal>.hi</literal> files</primary></indexterm>
  50       <indexterm><primary>object files</primary></indexterm>
  51       <indexterm><primary><literal>.o</literal> files</primary></indexterm>
  52
  53       <para>When asked to compile a source file, GHC normally
  54       generates two files: an <firstterm>object file</firstterm>, and
  55       an <firstterm>interface file</firstterm>. </para>
  56
  57       <para>The object file, which normally ends in a
  58       <literal>.o</literal> suffix (or <literal>.obj</literal> if
  59       you're on Windows), contains the compiled code for the module.</para>
  60
  61       <para>The interface file,
  62       which normally ends in a <literal>.hi</literal> suffix, contains
  63       the information that GHC needs in order to compile further
  64       modules that depend on this module.  It contains things like the
  65       types of exported functions, definitions of data types, and so
  66       on.  It is stored in a binary format, so don't try to read one;
  67       use the <option>--show-iface</option> option instead (see <xref
  68       linkend="hi-options"/>).</para>
  69
  70       <para>You should think of the object file and the interface file as a
  71       pair, since the interface file is in a sense a compiler-readable
  72       description of the contents of the object file.  If the
  73       interface file and object file get out of sync for any reason,
  74       then the compiler may end up making assumptions about the object
  75       file that aren't true; trouble will almost certainly follow.
  76       For this reason, we recommend keeping object files and interface
  77       files in the same place (GHC does this by default, but it is
  78       possible to override the defaults as we'll explain
  79       shortly).</para>
  80
  81       <para>Every module has a <emphasis>module name</emphasis>
  82       defined in its source code (<literal>module A.B.C where
  83       ...</literal>).</para>
  84
  85       <para>The name of the object file generated by GHC is derived
  86       according to the following rules, where
  87       <replaceable>osuf</replaceable> is the object-file suffix (this
  88       can be changed with the <option>-osuf</option> option).</para>
  89
  90       <itemizedlist>
  91         <listitem>
  92           <para>If there is no <option>-odir</option> option (the
  93           default), then the object filename is derived from the
  94           source filename (ignoring the module name) by replacing the
  95           suffix with <replaceable>osuf</replaceable>.</para>
  96         </listitem>
  97         <listitem>
  98           <para>If
  99           <option>-odir</option>&nbsp;<replaceable>dir</replaceable>
 100           has been specified, then the object filename is
 101           <replaceable>dir</replaceable>/<replaceable>mod</replaceable>.<replaceable>osuf</replaceable>,
 102           where <replaceable>mod</replaceable> is the module name with
 103           dots replaced by slashes.</para>
 104         </listitem>
 105       </itemizedlist>
 106
 107       <para>The name of the interface file is derived using the same
 108       rules, except that the suffix is
 109       <replaceable>hisuf</replaceable> (<literal>.hi</literal> by
 110       default) instead of <replaceable>osuf</replaceable>, and the
 111       relevant options are <option>-hidir</option> and
 112       <option>-hisuf</option> instead of <option>-odir</option> and
 113       <option>-osuf</option> respectively.</para>
 114
 115       <para>For example, if GHC compiles the module
 116       <literal>A.B.C</literal> in the file
 117       <filename>src/A/B/C.hs</filename>, with no
 118       <literal>-odir</literal> or <literal>-hidir</literal> flags, the
 119       interface file will be put in <literal>src/A/B/C.hi</literal>
 120       and the object file in <literal>src/A/B/C.o</literal>.</para>
 121
 122       <para>For any module that is imported, GHC requires that the
 123       name of the module in the import statement exactly matches the
 124       name of the module in the interface file (or source file) found
 125       using the strategy specified in <xref linkend="search-path"/>.
 126       This means that for most modules, the source file name should
 127       match the module name.</para>
 128
 129       <para>However, note that it is reasonable to have a module
 130       <literal>Main</literal> in a file named
 131       <filename>foo.hs</filename>, but this only works because GHC
 132       never needs to search for the interface for module
 133       <literal>Main</literal> (because it is never imported).  It is
 134       therefore possible to have several <literal>Main</literal>
 135       modules in separate source files in the same directory, and GHC
 136       will not get confused.</para>
 137
 138       <para>In batch compilation mode, the name of the object file can
 139       also be overridden using the <option>-o</option> option, and the
 140       name of the interface file can be specified directly using the
 141       <option>-ohi</option> option.</para>
 142     </sect2>
 143
 144     <sect2 id="search-path">
 145       <title>The search path</title>
 146
 147       <indexterm><primary>search path</primary>
 148       </indexterm>
 149       <indexterm><primary>interface files, finding them</primary></indexterm>
 150       <indexterm><primary>finding interface files</primary></indexterm>
 151
 152       <para>In your program, you import a module
 153       <literal>Foo</literal> by saying <literal>import Foo</literal>.
 154       In <option>--make</option> mode or GHCi, GHC will look for a
 155       source file for <literal>Foo</literal> and arrange to compile it
 156       first.  Without <option>--make</option>, GHC will look for the
 157       interface file for <literal>Foo</literal>, which should have
 158       been created by an earlier compilation of
 159       <literal>Foo</literal>.  GHC uses the same strategy in each of
 160       these cases for finding the appropriate file.</para>
 161
 162       <para>This strategy is as follows: GHC keeps a list of
 163       directories called the <firstterm>search path</firstterm>.  For
 164       each of these directories, it tries appending
 165       <replaceable>basename</replaceable><literal>.</literal><replaceable>extension</replaceable>
 166       to the directory, and checks whether the file exists.  The value
 167       of <replaceable>basename</replaceable> is the module name with
 168       dots replaced by the directory separator ('/' or '\', depending
 169       on the system), and <replaceable>extension</replaceable> is a
 170       source extension (<literal>hs</literal>, <literal>lhs</literal>)
 171       if we are in <option>--make</option> mode and GHCi, or
 172       <replaceable>hisuf</replaceable> otherwise.</para>
 173
 174       <para>For example, suppose the search path contains directories
 175       <literal>d1</literal>, <literal>d2</literal>, and
 176       <literal>d3</literal>, and we are in <literal>--make</literal>
 177       mode looking for the source file for a module
 178       <literal>A.B.C</literal>.  GHC will look in
 179       <literal>d1/A/B/C.hs</literal>, <literal>d1/A/B/C.lhs</literal>,
 180       <literal>d2/A/B/C.hs</literal>, and so on.</para>
 181
 182       <para>The search path by default contains a single directory:
 183       <quote>.</quote> (i.e. the current directory).  The following
 184       options can be used to add to or change the contents of the
 185       search path:</para>
 186
 187       <variablelist>
 188         <varlistentry>
 189           <term><option>-i<replaceable>dirs</replaceable></option></term>
 190           <listitem>
 191             <para><indexterm><primary><option>-i<replaceable>dirs</replaceable></option>
 192             </primary></indexterm>This flag appends a colon-separated
 193             list of <filename>dirs</filename> to the search path.</para>
 194           </listitem>
 195         </varlistentry>
 196
 197         <varlistentry>
 198           <term><option>-i</option></term>
 199           <listitem>
 200             <para>resets the search path back to nothing.</para>
 201           </listitem>
 202         </varlistentry>
 203       </variablelist>
 204
 205       <para>This isn't the whole story: GHC also looks for modules in
 206       pre-compiled libraries, known as packages.  See the section on
 207       packages (<xref linkend="packages"/>), for details.</para>
 208     </sect2>
 209
 210     <sect2 id="options-output">
 211       <title>Redirecting the compilation output(s)</title>
 212
 213       <indexterm><primary>output-directing options</primary></indexterm>
 214       <indexterm><primary>redirecting compilation output</primary></indexterm>
 215
 216       <variablelist>
 217         <varlistentry>
 218           <term>
 219             <option>-o</option> <replaceable>file</replaceable>
 220             <indexterm><primary><option>-o</option></primary></indexterm>
 221           </term>
 222           <listitem>
 223             <para>GHC's compiled output normally goes into a
 224             <filename>.hc</filename>, <filename>.o</filename>, etc.,
 225             file, depending on the last-run compilation phase.  The
 226             option <option>-o <replaceable>file</replaceable></option>
 227             re-directs the output of that last-run phase to
 228             <replaceable>file</replaceable>.</para>
 229
 230             <para>Note: this &ldquo;feature&rdquo; can be
 231             counterintuitive: <command>ghc -C -o foo.o
 232             foo.hs</command> will put the intermediate C code in the
 233             file <filename>foo.o</filename>, name
 234             notwithstanding!</para>
 235
 236             <para>This option is most often used when creating an
 237             executable file, to set the filename of the executable.
 238             For example:
 239 <screen>   ghc -o prog --make Main</screen>
 240
 241             will compile the program starting with module
 242             <literal>Main</literal>  and put the executable in the
 243             file <literal>prog</literal>.</para>
 244
 245             <para>Note: on Windows, if the result is an executable
 246             file, the extension "<filename>.exe</filename>" is added
 247             if the specified filename does not already have an
 248             extension.  Thus
 249 <programlisting>
 250    ghc -o foo Main.hs
 251 </programlisting>
 252           will compile and link the module
 253           <filename>Main.hs</filename>, and put the resulting
 254           executable in <filename>foo.exe</filename> (not
 255           <filename>foo</filename>).</para>
 256
 257           <para>If you use <command>ghc --make</command> and you don't
 258           use the <option>-o</option>, the name GHC will choose
 259           for the executable will be based on the name of the file
 260           containing the module <literal>Main</literal>.
 261           Note that with GHC the <literal>Main</literal> module doesn't
 262           have to be put in file <filename>Main.hs</filename>.
 263           Thus both
 264 <programlisting>
 265    ghc --make Prog
 266 </programlisting>
 267           and
 268 <programlisting>
 269    ghc --make Prog.hs
 270 </programlisting>
 271           will produce <filename>Prog</filename> (or
 272           <filename>Prog.exe</filename> if you are on Windows).</para>
 273           </listitem>
 274         </varlistentry>
 275
 276         <varlistentry>
 277           <term>
 278             <option>-odir</option> <replaceable>dir</replaceable>
 279             <indexterm><primary><option>-odir</option></primary></indexterm>
 280           </term>
 281           <listitem>
 282             <para>Redirects object files to directory
 283             <replaceable>dir</replaceable>.  For example:</para>
 284
 285 <screen>
 286 $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
 287 </screen>
 288
 289             <para>The object files, <filename>Foo.o</filename>,
 290             <filename>Bar.o</filename>, and
 291             <filename>Bumble.o</filename> would be put into a
 292             subdirectory named after the architecture of the executing
 293             machine (<filename>x86</filename>,
 294             <filename>mips</filename>, etc).</para>
 295
 296             <para>Note that the <option>-odir</option> option does
 297             <emphasis>not</emphasis> affect where the interface files
 298             are put; use the <option>-hidir</option> option for that.
 299             In the above example, they would still be put in
 300             <filename>parse/Foo.hi</filename>,
 301             <filename>parse/Bar.hi</filename>, and
 302             <filename>gurgle/Bumble.hi</filename>.</para>
 303           </listitem>
 304         </varlistentry>
 305
 306         <varlistentry>
 307           <term>
 308             <option>-ohi</option>  <replaceable>file</replaceable>
 309             <indexterm><primary><option>-ohi</option></primary></indexterm>
 310           </term>
 311           <listitem>
 312             <para>The interface output may be directed to another file
 313             <filename>bar2/Wurble.iface</filename> with the option
 314             <option>-ohi bar2/Wurble.iface</option> (not
 315             recommended).</para>
 316
 317             <para>WARNING: if you redirect the interface file
 318             somewhere that GHC can't find it, then the recompilation
 319             checker may get confused (at the least, you won't get any
 320             recompilation avoidance).  We recommend using a
 321             combination of <option>-hidir</option> and
 322             <option>-hisuf</option> options instead, if
 323             possible.</para>
 324
 325             <para>To avoid generating an interface at all, you could
 326             use this option to redirect the interface into the bit
 327             bucket: <literal>-ohi /dev/null</literal>, for
 328             example.</para>
 329           </listitem>
 330         </varlistentry>
 331
 332         <varlistentry>
 333           <term>
 334             <option>-hidir</option>  <replaceable>dir</replaceable>
 335             <indexterm><primary><option>-hidir</option></primary></indexterm>
 336           </term>
 337           <listitem>
 338             <para>Redirects all generated interface files into
 339             <replaceable>dir</replaceable>, instead of the
 340             default.</para>
 341           </listitem>
 342         </varlistentry>
 343
 344         <varlistentry>
 345           <term>
 346             <option>-stubdir</option>  <replaceable>dir</replaceable>
 347             <indexterm><primary><option>-stubdir</option></primary></indexterm>
 348           </term>
 349           <listitem>
 350             <para>Redirects all generated FFI stub files into
 351             <replaceable>dir</replaceable>.  Stub files are generated when the
 352             Haskell source contains a <literal>foreign export</literal> or
 353             <literal>foreign import "&amp;wrapper"</literal> declaration (see <xref
 354               linkend="foreign-export-ghc" />).  The <option>-stubdir</option>
 355               option behaves in exactly the same way as <option>-odir</option>
 356               and <option>-hidir</option> with respect to hierarchical
 357             modules.</para>
 358           </listitem>
 359         </varlistentry>
 360
 361         <varlistentry>
 362           <term>
 363             <option>-osuf</option> <replaceable>suffix</replaceable>
 364             <indexterm><primary><option>-osuf</option></primary></indexterm>
 365           </term>
 366           <term>
 367             <option>-hisuf</option> <replaceable>suffix</replaceable>
 368             <indexterm><primary><option>-hisuf</option></primary></indexterm>
 369           </term>
 370           <term>
 371             <option>-hcsuf</option> <replaceable>suffix</replaceable>
 372             <indexterm><primary><option>-hcsuf</option></primary></indexterm>
 373           </term>
 374           <listitem>
 375             <para>The <option>-osuf</option>
 376             <replaceable>suffix</replaceable> will change the
 377             <literal>.o</literal> file suffix for object files to
 378             whatever you specify.  We use this when compiling
 379             libraries, so that objects for the profiling versions of
 380             the libraries don't clobber the normal ones.</para>
 381
 382             <para>Similarly, the <option>-hisuf</option>
 383             <replaceable>suffix</replaceable> will change the
 384             <literal>.hi</literal> file suffix for non-system
 385             interface files (see <xref linkend="hi-options"/>).</para>
 386
 387             <para>Finally, the option <option>-hcsuf</option>
 388             <replaceable>suffix</replaceable> will change the
 389             <literal>.hc</literal> file suffix for compiler-generated
 390             intermediate C files.</para>
 391
 392             <para>The <option>-hisuf</option>/<option>-osuf</option>
 393             game is particularly useful if you want to compile a
 394             program both with and without profiling, in the same
 395             directory.  You can say:
 396             <screen>
 397               ghc ...</screen>
 398             to get the ordinary version, and
 399             <screen>
 400               ghc ... -osuf prof.o -hisuf prof.hi -prof -auto-all</screen>
 401             to get the profiled version.</para>
 402           </listitem>
 403         </varlistentry>
 404       </variablelist>
 405     </sect2>
 406
 407     <sect2 id="keeping-intermediates">
 408       <title>Keeping Intermediate Files</title>
 409       <indexterm><primary>intermediate files, saving</primary>
 410       </indexterm>
 411       <indexterm><primary><literal>.hc</literal> files, saving</primary>
 412       </indexterm>
 413       <indexterm><primary><literal>.s</literal> files, saving</primary>
 414       </indexterm>
 415
 416       <para>The following options are useful for keeping certain
 417       intermediate files around, when normally GHC would throw these
 418       away after compilation:</para>
 419
 420       <variablelist>
 421         <varlistentry>
 422           <term>
 423             <option>-keep-hc-files</option>
 424             <indexterm><primary><option>-keep-hc-files</option></primary></indexterm>
 425           </term>
 426           <listitem>
 427             <para>Keep intermediate <literal>.hc</literal> files when
 428             doing <literal>.hs</literal>-to-<literal>.o</literal>
 429             compilations via C (NOTE: <literal>.hc</literal> files
 430             aren't generated when using the native code generator, you
 431             may need to use <option>-fvia-C</option> to force them
 432             to be produced).</para>
 433           </listitem>
 434         </varlistentry>
 435
 436         <varlistentry>
 437           <term>
 438             <option>-keep-s-files</option>
 439             <indexterm><primary><option>-keep-s-files</option></primary></indexterm>
 440           </term>
 441           <listitem>
 442             <para>Keep intermediate <literal>.s</literal> files.</para>
 443           </listitem>
 444         </varlistentry>
 445
 446         <varlistentry>
 447           <term>
 448             <option>-keep-raw-s-files</option>
 449             <indexterm><primary><option>-keep-raw-s-files</option></primary></indexterm>
 450           </term>
 451           <listitem>
 452             <para>Keep intermediate <literal>.raw-s</literal> files.
 453             These are the direct output from the C compiler, before
 454             GHC does &ldquo;assembly mangling&rdquo; to produce the
 455             <literal>.s</literal> file.  Again, these are not produced
 456             when using the native code generator.</para>
 457           </listitem>
 458         </varlistentry>
 459
 460         <varlistentry>
 461           <term>
 462             <option>-keep-tmp-files</option>
 463             <indexterm><primary><option>-keep-tmp-files</option></primary></indexterm>
 464             <indexterm><primary>temporary files</primary><secondary>keeping</secondary></indexterm>
 465           </term>
 466           <listitem>
 467             <para>Instructs the GHC driver not to delete any of its
 468             temporary files, which it normally keeps in
 469             <literal>/tmp</literal> (or possibly elsewhere; see <xref
 470             linkend="temp-files"/>).  Running GHC with
 471             <option>-v</option> will show you what temporary files
 472             were generated along the way.</para>
 473           </listitem>
 474         </varlistentry>
 475       </variablelist>
 476     </sect2>
 477
 478     <sect2 id="temp-files">
 479       <title>Redirecting temporary files</title>
 480
 481       <indexterm>
 482         <primary>temporary files</primary>
 483         <secondary>redirecting</secondary>
 484       </indexterm>
 485
 486       <variablelist>
 487         <varlistentry>
 488           <term>
 489             <option>-tmpdir</option>
 490             <indexterm><primary><option>-tmpdir</option></primary></indexterm>
 491           </term>
 492           <listitem>
 493             <para>If you have trouble because of running out of space
 494             in <filename>/tmp</filename> (or wherever your
 495             installation thinks temporary files should go), you may
 496             use the <option>-tmpdir
 497             &lt;dir&gt;</option><indexterm><primary>-tmpdir
 498             &lt;dir&gt; option</primary></indexterm> option to specify
 499             an alternate directory.  For example, <option>-tmpdir
 500             .</option> says to put temporary files in the current
 501             working directory.</para>
 502
 503             <para>Alternatively, use your <constant>TMPDIR</constant>
 504             environment variable.<indexterm><primary>TMPDIR
 505             environment variable</primary></indexterm> Set it to the
 506             name of the directory where temporary files should be put.
 507             GCC and other programs will honour the
 508             <constant>TMPDIR</constant> variable as well.</para>
 509
 510             <para>Even better idea: Set the
 511             <constant>DEFAULT_TMPDIR</constant> make variable when
 512             building GHC, and never worry about
 513             <constant>TMPDIR</constant> again. (see the build
 514             documentation).</para>
 515           </listitem>
 516         </varlistentry>
 517       </variablelist>
 518     </sect2>
 519
 520     <sect2 id="hi-options">
 521       <title>Other options related to interface files</title>
 522       <indexterm><primary>interface files, options</primary></indexterm>
 523
 524       <variablelist>
 525         <varlistentry>
 526           <term>
 527             <option>-ddump-hi</option>
 528             <indexterm><primary><option>-ddump-hi</option></primary></indexterm>
 529           </term>
 530           <listitem>
 531             <para>Dumps the new interface to standard output.</para>
 532           </listitem>
 533         </varlistentry>
 534
 535         <varlistentry>
 536           <term>
 537             <option>-ddump-hi-diffs</option>
 538             <indexterm><primary><option>-ddump-hi-diffs</option></primary></indexterm>
 539           </term>
 540           <listitem>
 541             <para>The compiler does not overwrite an existing
 542             <filename>.hi</filename> interface file if the new one is
 543             the same as the old one; this is friendly to
 544             <command>make</command>.  When an interface does change,
 545             it is often enlightening to be informed.  The
 546             <option>-ddump-hi-diffs</option> option will make GHC run
 547             <command>diff</command> on the old and new
 548             <filename>.hi</filename> files.</para>
 549           </listitem>
 550         </varlistentry>
 551
 552         <varlistentry>
 553           <term>
 554             <option>-ddump-minimal-imports</option>
 555             <indexterm><primary><option>-ddump-minimal-imports</option></primary></indexterm>
 556           </term>
 557           <listitem>
 558             <para>Dump to the file "M.imports" (where M is the module
 559             being compiled) a "minimal" set of import declarations.
 560             You can safely replace all the import declarations in
 561             "M.hs" with those found in "M.imports".  Why would you
 562             want to do that?  Because the "minimal" imports (a) import
 563             everything explicitly, by name, and (b) import nothing
 564             that is not required.  It can be quite painful to maintain
 565             this property by hand, so this flag is intended to reduce
 566             the labour.</para>
 567           </listitem>
 568         </varlistentry>
 569
 570         <varlistentry>
 571           <term>
 572             <option>--show-iface</option> <replaceable>file</replaceable>
 573             <indexterm><primary><option>--show-iface</option></primary></indexterm>
 574           </term>
 575           <listitem>
 576             <para>Where <replaceable>file</replaceable> is the name of
 577             an interface file, dumps the contents of that interface in
 578             a human-readable (ish) format.</para>
 579           </listitem>
 580         </varlistentry>
 581       </variablelist>
 582     </sect2>
 583
 584     <sect2 id="recomp">
 585       <title>The recompilation checker</title>
 586
 587       <indexterm><primary>recompilation checker</primary></indexterm>
 588
 589       <variablelist>
 590         <varlistentry>
 591           <term>
 592             <option>-no-recomp</option>
 593             <indexterm><primary><option>-recomp</option></primary></indexterm>
 594             <indexterm><primary><option>-no-recomp</option></primary></indexterm>
 595           </term>
 596           <listitem>
 597             <para>Turn off recompilation checking (which is on by
 598             default).  Recompilation checking normally stops
 599             compilation early, leaving an existing
 600             <filename>.o</filename> file in place, if it can be
 601             determined that the module does not need to be
 602             recompiled.</para>
 603           </listitem>
 604         </varlistentry>
 605       </variablelist>
 606
 607       <para>In the olden days, GHC compared the newly-generated
 608       <filename>.hi</filename> file with the previous version; if they
 609       were identical, it left the old one alone and didn't change its
 610       modification date.  In consequence, importers of a module with
 611       an unchanged output <filename>.hi</filename> file were not
 612       recompiled.</para>
 613
 614       <para>This doesn't work any more.  Suppose module
 615       <literal>C</literal> imports module <literal>B</literal>, and
 616       <literal>B</literal> imports module <literal>A</literal>.  So
 617       changes to module <literal>A</literal> might require module
 618       <literal>C</literal> to be recompiled, and hence when
 619       <filename>A.hi</filename> changes we should check whether
 620       <literal>C</literal> should be recompiled.  However, the
 621       dependencies of <literal>C</literal> will only list
 622       <literal>B.hi</literal>, not <literal>A.hi</literal>, and some
 623       changes to <literal>A</literal> (changing the definition of a
 624       function that appears in an inlining of a function exported by
 625       <literal>B</literal>, say) may conceivably not change
 626       <filename>B.hi</filename> one jot.  So now&hellip;</para>
 627
 628       <para>GHC keeps a version number on each interface file, and on
 629       each type signature within the interface file.  It also keeps in
 630       every interface file a list of the version numbers of everything
 631       it used when it last compiled the file.  If the source file's
 632       modification date is earlier than the <filename>.o</filename>
 633       file's date (i.e. the source hasn't changed since the file was
 634       last compiled), and the recompilation checking is on, GHC will be
 635       clever.  It compares the version numbers on the things it needs
 636       this time with the version numbers on the things it needed last
 637       time (gleaned from the interface file of the module being
 638       compiled); if they are all the same it stops compiling rather
 639       early in the process saying &ldquo;Compilation IS NOT
 640       required&rdquo;.  What a beautiful sight!</para>
 641
 642       <para>Patrick Sansom had a workshop paper about how all this is
 643       done (though the details have changed quite a bit). <ulink
 644       url="mailto:sansom@dcs.gla.ac.uk">Ask him</ulink> if you want a
 645       copy.</para>
 646
 647     </sect2>
 648
 649     <sect2 id="mutual-recursion">
 650       <title>How to compile mutually recursive modules</title>
 651
 652       <indexterm><primary>module system, recursion</primary></indexterm>
 653       <indexterm><primary>recursion, between modules</primary></indexterm>
 654
 655       <para>GHC supports the compilation of mutually recursive modules.
 656       This section explains how.</para>
 657
 658       <para>Every cycle in the module import graph must be broken by a <filename>hs-boot</filename> file.
 659       Suppose that modules <filename>A.hs</filename> and <filename>B.hs</filename> are Haskell source files,
 660       thus:
 661 <programlisting>
 662 module A where
 663     import B( TB(..) )
 664
 665     newtype TA = MkTA Int
 666
 667     f :: TB -&#62; TA
 668     f (MkTB x) = MkTA x
 669
 670 module B where
 671     import {-# SOURCE #-} A( TA(..) )
 672
 673     data TB = MkTB !Int
 674
 675     g :: TA -&#62; TB
 676     g (MkTA x) = MkTB x
 677 </programlisting>
 678 <indexterm><primary><literal>hs-boot</literal>
 679       files</primary></indexterm> <indexterm><primary>importing,
 680       <literal>hi-boot</literal> files</primary></indexterm>
 681 Here <filename>A</filename> imports <filename>B</filename>, but <filename>B</filename> imports
 682 <filename>A</filename> with a <literal>{-# SOURCE #-}</literal> pragma, which breaks the
 683 circular dependency.  For every module <filename>A.hs</filename> that is <literal>{-# SOURCE #-}</literal>-imported
 684 in this way there must exist a souce file <literal>A.hs-boot</literal>.  This file contains an abbreviated
 685 version of <filename>A.hs</filename>, thus:
 686 <programlisting>
 687 module A where
 688     newtype TA = MkTA Int
 689 </programlisting>
 690 </para>
 691 <para>To compile these three files, issue the following commands:
 692 <programlisting>
 693   ghc -c A.hs-boot    -- Poduces A.hi-boot, A.o-boot
 694   ghc -c B.hs         -- Consumes A.hi-boot, produces B.hi, B.o
 695   ghc -c A.hs         -- Consumes B.hi, produces A.hi, A.o
 696   ghc -o foo A.o B.o  -- Linking the program
 697 </programlisting>
 698 </para>
 699 <para>There are several points to note here:
 700 <itemizedlist>
 701 <listitem>
 702   <para>The file <filename>A.hs-boot</filename> is a programmer-written source file.
 703   It must live in the same directory as its parent source file <filename>A.hs</filename>.
 704   Currently, if you use a literate source file <filename>A.lhs</filename> you must
 705   also use a literate boot file, <filename>A.lhs-boot</filename>; and vice versa.
 706   </para></listitem>
 707
 708 <listitem><para>
 709   A <filename>hs-boot</filename> file is compiled by GHC, just like a <filename>hs</filename> file:
 710 <programlisting>
 711   ghc -c A.hs-boot
 712 </programlisting>
 713 When a hs-boot file <filename>A.hs-boot</filename>
 714    is compiled, it is checked for scope and type errors.
 715    When its parent module <filename>A.hs</filename> is compiled, the two are compared, and
 716    an error is reported if the two are inconsistent.
 717    </para></listitem>
 718
 719         <listitem>
 720           <para> Just as compiling <filename>A.hs</filename> produces an
 721             interface file <filename>A.hi</filename>, and an object file
 722             <filename>A.o</filename>, so compiling
 723             <filename>A.hs-boot</filename> produces an interface file
 724             <filename>A.hi-boot</filename>, and an pseudo-object file
 725             <filename>A.o-boot</filename>: </para>
 726
 727           <itemizedlist>
 728             <listitem>
 729               <para>The pseudo-object file <filename>A.o-boot</filename> is
 730                 empty (don't link it!), but it is very useful when using a
 731                 Makefile, to record when the <filename>A.hi-boot</filename> was
 732                 last brought up to date (see <xref
 733                   linkend="using-make"/>).</para>
 734             </listitem>
 735
 736             <listitem>
 737               <para>The <filename>hi-boot</filename> generated by compiling a
 738                 <filename>hs-boot</filename> file is in the same
 739                 machine-generated binary format as any other GHC-generated
 740                 interface file (e.g. <filename>B.hi</filename>). You can
 741                 display its contents with <command>ghc
 742                   --show-iface</command>. If you specify a directory for
 743                 interface files, the <option>-ohidir</option> flag, then that
 744                 affects <filename>hi-boot</filename> files
 745                 too.</para>
 746             </listitem>
 747           </itemizedlist>
 748         </listitem>
 749
 750    <listitem><para> If hs-boot files are considered distinct from their parent source
 751    files, and if a <literal>{-# SOURCE #-}</literal> import is considered to refer to the
 752    hs-boot file, then the module import graph must have no cycles.  The command
 753    <command>ghc -M</command> will report an error if a cycle is found.
 754    </para></listitem>
 755
 756    <listitem><para> A module <literal>M</literal> that is
 757    <literal>{-# SOURCE #-}</literal>-imported in a program will usually also be
 758    ordinarily imported elsewhere.  If not, <command>ghc --make</command>
 759    automatically adds <literal>M</literal> to the set of moudles it tries to
 760    compile and link, to ensure that <literal>M</literal>'s implementation is included in
 761    the final program.
 762    </para></listitem>
 763 </itemizedlist>
 764 </para>
 765 <para>
 766 A hs-boot file need only contain the bare
 767       minimum of information needed to get the bootstrapping process
 768       started.  For example, it doesn't need to contain declarations
 769       for <emphasis>everything</emphasis> that module
 770       <literal>A</literal> exports, only the things required by the
 771       module(s) that import <literal>A</literal> recursively.</para>
 772 <para>A hs-boot file is written in a subset of Haskell:
 773 <itemizedlist>
 774 <listitem><para> The module header (including the export list), and import statements, are exactly as in
 775 Haskell, and so are the scoping rules.
 776    Hence, to mention a non-Prelude type or class, you must import it.</para></listitem>
 777
 778 <listitem><para> There must be no value declarations, but there can be type signatures for
 779 values.  For example:
 780 <programlisting>
 781   double :: Int -&#62; Int
 782 </programlisting>
 783 </para></listitem>
 784 <listitem><para> Fixity declarations are exactly as in Haskell.</para></listitem>
 785 <listitem><para> Type synonym declarations are exactly as in Haskell.</para></listitem>
 786 <listitem><para> A data type declaration can either be given in full, exactly as in Haskell, or it
 787 can be given abstractly, by omitting the '=' sign and everything that follows.  For example:
 788 <programlisting>
 789   data T a b
 790 </programlisting>
 791             In a <emphasis>source</emphasis> program
 792           this would declare TA to have no constructors (a GHC extension: see <xref linkend="nullary-types"/>),
 793           but in an hi-boot file it means "I don't know or care what the constructors are".
 794             This is the most common form of data type declaration, because it's easy to get right.
 795           You <emphasis>can</emphasis> also write out the constructors but, if you do so, you must write
 796           it out precisely as in its real definition.</para>
 797           <para>
 798             If you do not write out the constructors, you may need to give a kind
 799             annotation (<xref linkend="sec-kinding"/>), to tell
 800             GHC the kind of the type variable, if it is not "*".  (In source files, this is worked out
 801             from the way the type variable is used in the constructors.)  For example:
 802 <programlisting>
 803   data R (x :: * -&#62; *) y
 804 </programlisting>
 805 </para></listitem>
 806 <listitem><para> Class declarations is exactly as in Haskell, except that you may not put
 807 default method declarations.  You can also omit all the class methods entirely.
 808 </para></listitem>
 809 <listitem><para> Do not include instance declarations. There is a complication to do with
 810 how the dictionary functions are named.  It may well work, but it's not a well-tested feature.
 811  </para></listitem>
 812 </itemizedlist>
 813 </para>
 814     </sect2>
 815
 816
 817     <sect2 id="using-make">
 818       <title>Using <command>make</command></title>
 819
 820       <indexterm><primary><literal>make</literal></primary></indexterm>
 821
 822       <para>It is reasonably straightforward to set up a
 823       <filename>Makefile</filename> to use with GHC, assuming you name
 824       your source files the same as your modules.  Thus:</para>
 825
 826 <programlisting>
 827 HC      = ghc
 828 HC_OPTS = -cpp $(EXTRA_HC_OPTS)
 829
 830 SRCS = Main.lhs Foo.lhs Bar.lhs
 831 OBJS = Main.o   Foo.o   Bar.o
 832
 833 .SUFFIXES : .o .hs .hi .lhs .hc .s
 834
 835 cool_pgm : $(OBJS)
 836         rm -f $@
 837         $(HC) -o $@ $(HC_OPTS) $(OBJS)
 838
 839 # Standard suffix rules
 840 .o.hi:
 841         @:
 842
 843 .lhs.o:
 844         $(HC) -c $&#60; $(HC_OPTS)
 845
 846 .hs.o:
 847         $(HC) -c $&#60; $(HC_OPTS)
 848
 849 .o-boot.hi-boot:
 850         @:
 851
 852 .lhs-boot.o-boot:
 853         $(HC) -c $&#60; $(HC_OPTS)
 854
 855 .hs-boot.o-boot:
 856         $(HC) -c $&#60; $(HC_OPTS)
 857
 858 # Inter-module dependencies
 859 Foo.o Foo.hc Foo.s    : Baz.hi          # Foo imports Baz
 860 Main.o Main.hc Main.s : Foo.hi Baz.hi   # Main imports Foo and Baz
 861 </programlisting>
 862
 863       <para>(Sophisticated <command>make</command> variants may
 864       achieve some of the above more elegantly.  Notably,
 865       <command>gmake</command>'s pattern rules let you write the more
 866       comprehensible:</para>
 867
 868 <programlisting>
 869 %.o : %.lhs
 870         $(HC) -c $&#60; $(HC_OPTS)
 871 </programlisting>
 872
 873       <para>What we've shown should work with any
 874       <command>make</command>.)</para>
 875
 876       <para>Note the cheesy <literal>.o.hi</literal> rule: It records
 877       the dependency of the interface (<filename>.hi</filename>) file
 878       on the source.  The rule says a <filename>.hi</filename> file
 879       can be made from a <filename>.o</filename> file by
 880       doing&hellip;nothing.  Which is true.</para>
 881       <para> Note that the suffix rules are all repeated twice, once
 882       for normal Haskell source files, and once for <filename>hs-boot</filename>
 883       files (see <xref linkend="mutual-recursion"/>).</para>
 884
 885       <para>Note also the inter-module dependencies at the end of the
 886       Makefile, which take the form
 887
 888 <programlisting>
 889 Foo.o Foo.hc Foo.s    : Baz.hi          # Foo imports Baz
 890 </programlisting>
 891
 892       They tell <command>make</command> that if any of
 893       <literal>Foo.o</literal>, <literal>Foo.hc</literal> or
 894       <literal>Foo.s</literal> have an earlier modification date than
 895       <literal>Baz.hi</literal>, then the out-of-date file must be
 896       brought up to date.  To bring it up to date,
 897       <literal>make</literal> looks for a rule to do so; one of the
 898       preceding suffix rules does the job nicely.  These dependencies
 899       can be generated automatically by <command>ghc</command>; see
 900       <xref linkend="sec-makefile-dependencies"/></para>
 901
 902  </sect2>
 903
 904       <sect2 id="sec-makefile-dependencies">
 905         <title>Dependency generation</title>
 906         <indexterm><primary>dependencies in Makefiles</primary></indexterm>
 907         <indexterm><primary>Makefile dependencies</primary></indexterm>
 908
 909         <para>Putting inter-dependencies of the form <literal>Foo.o :
 910         Bar.hi</literal> into your <filename>Makefile</filename> by
 911         hand is rather error-prone.  Don't worry, GHC has support for
 912         automatically generating the required dependencies.  Add the
 913         following to your <filename>Makefile</filename>:</para>
 914
 915 <programlisting>
 916 depend :
 917         ghc -M $(HC_OPTS) $(SRCS)
 918 </programlisting>
 919
 920         <para>Now, before you start compiling, and any time you change
 921         the <literal>imports</literal> in your program, do
 922         <command>make depend</command> before you do <command>make
 923         cool&lowbar;pgm</command>.  The command <command>ghc -M</command> will
 924         append the needed dependencies to your
 925         <filename>Makefile</filename>.</para>
 926
 927         <para>In general, <command>ghc -M Foo</command> does the following.
 928         For each module <literal>M</literal> in the set
 929         <literal>Foo</literal> plus all its imports (transitively),
 930         it adds to the Makefile:
 931         <itemizedlist>
 932         <listitem><para>A line recording the dependence of the object file on the source file.
 933 <programlisting>
 934 M.o : M.hs
 935 </programlisting>
 936 (or <literal>M.lhs</literal> if that is the filename you used).
 937        </para></listitem>
 938        <listitem><para> For each import declaration <literal>import X</literal> in <literal>M</literal>,
 939        a line recording the dependence of <literal>M</literal> on <literal>X</literal>:
 940 <programlisting>
 941 M.o : X.hi
 942 </programlisting></para></listitem>
 943        <listitem><para> For each import declaration <literal>import {-# SOURCE #-} X</literal> in <literal>M</literal>,
 944        a line recording the dependence of <literal>M</literal> on <literal>X</literal>:
 945 <programlisting>
 946 M.o : X.hi-boot
 947 </programlisting>
 948        (See <xref linkend="mutual-recursion"/> for details of
 949        <literal>hi-boot</literal> style interface files.)
 950       </para></listitem>
 951         </itemizedlist>
 952         If <literal>M</literal> imports multiple modules, then there will
 953        be multiple lines with <filename>M.o</filename> as the
 954        target.</para>
 955        <para>There is no need to list all of the source files as arguments to the <command>ghc -M</command> command;
 956        <command>ghc</command> traces the dependencies, just like <command>ghc --make</command>
 957        (a new feature in GHC 6.4).</para>
 958
 959     <para>Note that <literal>ghc -M</literal> needs to find a <emphasis>source
 960         file</emphasis> for each module in the dependency graph, so that it can
 961       parse the import declarations and follow dependencies.  Any pre-compiled
 962       modules without source files must therefore belong to a
 963       package<footnote><para>This is a change in behaviour relative to 6.2 and
 964         earlier.</para>
 965       </footnote>.</para>
 966
 967         <para>By default, <command>ghc -M</command> generates all the
 968         dependencies, and then concatenates them onto the end of
 969         <filename>makefile</filename> (or
 970         <filename>Makefile</filename> if <filename>makefile</filename>
 971         doesn't exist) bracketed by the lines "<literal>&num; DO NOT
 972         DELETE: Beginning of Haskell dependencies</literal>" and
 973         "<literal>&num; DO NOT DELETE: End of Haskell
 974         dependencies</literal>".  If these lines already exist in the
 975         <filename>makefile</filename>, then the old dependencies are
 976         deleted first.</para>
 977
 978         <para>Don't forget to use the same <option>-package</option>
 979         options on the <literal>ghc -M</literal> command line as you
 980         would when compiling; this enables the dependency generator to
 981         locate any imported modules that come from packages.  The
 982         package modules won't be included in the dependencies
 983         generated, though (but see the
 984         <option>&ndash;&ndash;include-pkg-deps</option> option below).</para>
 985
 986         <para>The dependency generation phase of GHC can take some
 987         additional options, which you may find useful.  For historical
 988         reasons, each option passed to the dependency generator from
 989         the GHC command line must be preceded by
 990         <literal>-optdep</literal>.  For example, to pass <literal>-f
 991         .depend</literal> to the dependency generator, you say
 992
 993 <screen>
 994 ghc -M -optdep-f -optdep.depend ...
 995 </screen>
 996
 997         The options which affect dependency generation are:</para>
 998
 999         <variablelist>
1000           <varlistentry>
1001             <term><option>-w</option></term>
1002             <listitem>
1003               <para>Turn off warnings about interface file shadowing.</para>
1004             </listitem>
1005           </varlistentry>
1006
1007           <varlistentry>
1008             <term><option>-v2</option></term>
1009             <listitem>
1010               <para>Print a full list of the module depenencies to stdout.
1011                     (This is the standard verbosity flag, so the list will
1012               also be displayed with <option>-v3</option> and
1013               <option>-v4</option>;
1014               <xref linkend ="options-help"/>.)</para>
1015             </listitem>
1016           </varlistentry>
1017
1018           <varlistentry>
1019             <term><option>-f</option> <replaceable>file</replaceable></term>
1020             <listitem>
1021               <para>Use <replaceable>file</replaceable> as the makefile,
1022               rather than <filename>makefile</filename> or
1023               <filename>Makefile</filename>.  If
1024               <replaceable>file</replaceable> doesn't exist,
1025               <command>mkdependHS</command> creates it.  We often use
1026               <option>-f .depend</option> to put the dependencies in
1027               <filename>.depend</filename> and then
1028               <command>include</command> the file
1029               <filename>.depend</filename> into
1030               <filename>Makefile</filename>.</para>
1031             </listitem>
1032           </varlistentry>
1033
1034 <!-- Retired with the move away from 'mkdependHS'.
1035           <varlistentry>
1036             <term><option>-o &lt;osuf&gt;</option></term>
1037             <listitem>
1038               <para>Use <filename>.&lt;osuf&gt;</filename> as the
1039               "target file" suffix ( default: <literal>o</literal>).
1040               Multiple <option>-o</option> flags are permitted
1041               (GHC2.05 onwards).  Thus "<option>-o hc -o o</option>"
1042               will generate dependencies for <filename>.hc</filename>
1043               and <filename>.o</filename> files.</para>
1044             </listitem>
1045           </varlistentry>
1046 -->
1047           <varlistentry>
1048             <term><option>-s &lt;suf&gt;</option></term>
1049             <listitem>
1050               <para>Make extra dependencies that declare that files
1051               with suffix
1052               <filename>.&lt;suf&gt;&lowbar;&lt;osuf&gt;</filename>
1053               depend on interface files with suffix
1054               <filename>.&lt;suf&gt;&lowbar;hi</filename>, or (for
1055               <literal>&lcub;-&num; SOURCE &num;-&rcub;</literal>
1056               imports) on <filename>.hi-boot</filename>.  Multiple
1057               <option>-s</option> flags are permitted.  For example,
1058               <option>-o hc -s a -s b</option> will make dependencies
1059               for <filename>.hc</filename> on
1060               <filename>.hi</filename>,
1061               <filename>.a&lowbar;hc</filename> on
1062               <filename>.a&lowbar;hi</filename>, and
1063               <filename>.b&lowbar;hc</filename> on
1064               <filename>.b&lowbar;hi</filename>.  (Useful in
1065               conjunction with NoFib "ways".)</para>
1066             </listitem>
1067           </varlistentry>
1068
1069           <varlistentry>
1070             <term><option>&ndash;&ndash;exclude-module=&lt;file&gt;</option></term>
1071             <listitem>
1072               <para>Regard <filename>&lt;file&gt;</filename> as
1073               "stable"; i.e., exclude it from having dependencies on
1074               it.</para>
1075             </listitem>
1076           </varlistentry>
1077
1078           <varlistentry>
1079             <term><option>-x</option></term>
1080             <listitem>
1081               <para>same as <option>&ndash;&ndash;exclude-module</option></para>
1082             </listitem>
1083           </varlistentry>
1084
1085           <varlistentry>
1086             <term><option>&ndash;&ndash;exclude-directory=&lt;dirs&gt;</option></term>
1087             <listitem>
1088               <para>Regard the colon-separated list of directories
1089               <filename>&lt;dirs&gt;</filename> as containing stable,
1090               don't generate any dependencies on modules
1091               therein.</para>
1092             </listitem>
1093           </varlistentry>
1094
1095           <varlistentry>
1096             <term><option>&ndash;&ndash;include-module=&lt;file&gt;</option></term>
1097             <listitem>
1098               <para>Regard <filename>&lt;file&gt;</filename> as not
1099               "stable"; i.e., generate dependencies on it (if
1100               any). This option is normally used in conjunction with
1101               the <option>&ndash;&ndash;exclude-directory</option> option.</para>
1102             </listitem>
1103           </varlistentry>
1104
1105           <varlistentry>
1106             <term><option>&ndash;&ndash;include-pkg-deps</option></term>
1107             <listitem>
1108               <para>Regard modules imported from packages as unstable,
1109               i.e., generate dependencies on any imported package modules
1110               (including <literal>Prelude</literal>, and all other
1111               standard Haskell libraries).  Dependencies are not traced
1112               recursively into packages; dependencies are only generated for
1113               home-package modules on external-package modules directly imported
1114               by the home package module.
1115               This option is normally
1116               only used by the various system libraries.</para>
1117             </listitem>
1118           </varlistentry>
1119         </variablelist>
1120
1121     </sect2>
1122
1123     <sect2 id="orphan-modules">
1124       <title>Orphan modules and instance declarations</title>
1125
1126 <para> Haskell specifies that when compiling module M, any instance
1127 declaration in any module "below" M is visible.  (Module A is "below"
1128 M if A is imported directly by M, or if A is below a module that M imports directly.)
1129 In principle, GHC must therefore read the interface files of every module below M,
1130 just in case they contain an instance declaration that matters to M.  This would
1131 be a disaster in practice, so GHC tries to be clever. </para>
1132
1133 <para>In particular, if an instance declaration is in the same module as the definition
1134 of any type or class mentioned in the head of the instance declaration, then
1135 GHC has to visit that interface file anyway.  Example:</para>
1136 <programlisting>
1137   module A where
1138     instance C a =&gt; D (T a) where ...
1139     data T a = ...
1140 </programlisting>
1141 <para> The instance declaration is only relevant if the type T is in use, and if
1142 so, GHC will have visited A's interface file to find T's definition. </para>
1143
1144 <para> The only problem comes when a module contains an instance declaration
1145 and GHC has no other reason for visiting the module.  Example:
1146 <programlisting>
1147   module Orphan where
1148     instance C a =&gt; D (T a) where ...
1149     class C a where ...
1150 </programlisting>
1151 Here, neither D nor T is declared in module Orphan.
1152 We call such modules ``orphan modules'',
1153 defined thus:</para>
1154 <itemizedlist>
1155   <listitem> <para> An <emphasis>orphan module</emphasis>
1156   <indexterm><primary>orphan module</primary></indexterm>
1157   contains at least one <emphasis>orphan instance</emphasis> or at
1158   least one <emphasis>orphan rule</emphasis>.</para> </listitem>
1159
1160   <listitem><para> An instance declaration in a module M is an <emphasis>orphan instance</emphasis> if
1161   <indexterm><primary>orphan instance</primary></indexterm>
1162   none of the type constructors
1163   or classes mentioned in the instance head (the part after the ``<literal>=&gt;</literal>'') are declared
1164   in M.</para>
1165
1166   <para> Only the instance head counts.  In the example above, it is not good enough for C's declaration
1167   to be in module A; it must be the declaration of D or T.</para>
1168   </listitem>
1169
1170   <listitem><para> A rewrite rule in a module M is an <emphasis>orphan rule</emphasis>
1171   <indexterm><primary>orphan rule</primary></indexterm>
1172   if none of the variables, type constructors,
1173   or classes that are free in the left hand side of the rule are declared in M.
1174   </para> </listitem>
1175  </itemizedlist>
1176
1177
1178 <para> GHC identifies orphan modules, and visits the interface file of
1179 every orphan module below the module being compiled.  This is usually
1180 wasted work, but there is no avoiding it.  You should therefore do
1181 your best to have as few orphan modules as possible.
1182
1183 </para>
1184
1185 <para> You can identify an orphan module by looking in its interface
1186 file, <filename>M.hi</filename>, using the
1187 <option>--show-iface</option>.  If there is a ``!'' on the first line,
1188 GHC considers it an orphan module.
1189 </para>
1190 </sect2>
1191
1192   </sect1>
1193
1194 <!-- Emacs stuff:
1195      ;;; Local Variables: ***
1196      ;;; mode: xml ***
1197      ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
1198      ;;; End: ***
1199  -->