declaration is missing one or more methods, and the corresponding
class declaration has no default declaration for them.
+<tag>@-fwarn-missing-fields@:</tag>
+<nidx>-fwarn-missing-fields option</nidx>
+<nidx>missing fields, warning</nidx>
+<nidx>fields, missing</nidx>
+
+This option is on by default, and warns you whenever the construction
+of a labelled field constructor isn't complete, missing initializers
+for one or more fields. While not an error (the missing fields are
+initialised with bottoms), it is often an indication of a programmer
+error.
+
<tag>@-fwarn-unused-imports@:</tag>
<nidx>-fwarn-unused-imports option</nidx>
<nidx>unused imports, warning</nidx>
<tag>@-i<dirs>@</tag><nidx>-i<dirs> option</nidx> This flag
prepends a colon-separated list of @dirs@ to the ``import
directories'' list.
+See also Section <ref id="recomp"> for the significance of using
+relative and absolute pathnames in the @-i@ list.
<tag>@-i@</tag> resets the ``import directories'' list back to nothing.
file a list of the version numbers of everything it used when it last
compiled the file. If the source file's modification date is earlier
than the @.o@ file's date (i.e. the source hasn't changed since the
-file was last compiled), and you give GHC the @-recomp@<nidx>-recomp
-option</nidx> flag, then GHC will be clever. It compares the version
+file was last compiled), GHC will be clever. It compares the version
numbers on the things it needs this time with the version numbers 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
rather early in the process saying ``Compilation IS NOT required''.
What a beautiful sight!
-It's still an experimental feature (that's why @-recomp@ is off by
-default), so tell us if you think it doesn't work.
+GHC <em>only</em> keeps detailed dependency information for ``user'' modules,
+not for ``library'' modules. It distinguishes the two by a hack: a module
+whose @.hi@ file has an absolute path name is considered a library module,
+while a relative path name indicates a user module. So if you have a
+multi-directory application, use <em>relative</em> path names in your
+@-i@ path, to force GHC to record detailed dependency information.
+Use absolute path names only for directories containing slowly-changing
+library modules.
-Patrick Sansom has a workshop paper about how all this is done. Ask
+A path is considered ``absolute'' if it starts with ``@/@'', or
+``@A:/@'', or ``@A:\@'' (or ``@B:/@'', ``@B:\@'' etc).
+
+Patrick Sansom had a workshop paper about how all this is done (though
+the details have changed quite a bit). Ask
him (email: <htmlurl name="sansom@@dcs.gla.ac.uk"
url="mailto:sansom@@dcs.gla.ac.uk">) if you want a copy.
import B
-newtype A = A Int
+newtype TA = MkTA Int
-f :: B -> A
-f (B x) = A x
+f :: TB -> TA
+f (MkTB x) = MkTA x
--------
module B where
import A
-data B = B !Int
+data TB = MkTB !Int
-g :: A -> B
-g (A x) = B x
+g :: TA -> TB
+g (MkTA x) = MkTB x
</verb></tscreen>
When compiling either module A and B, the compiler will try (in vain)
the following:
<tscreen><verb>
-__interface A 1 where
-__exports A A f;
-__import PrelBase Int;
-1 newtype A = A PrelBase.Int ;
-1 f :: A -> A ;
+__interface A 1 404 where
+__export A TA{MkTA} ;
+1 newtype TA = MkTA PrelBase.Int ;
</verb></tscreen>
The syntax is essentially the same as a normal @.hi@ file
(unfortunately), but you can usually tailor an existing @.hi@ file to
make a @.hi-boot@ file.
-Notice that we only put the declaration for the newtype @A@ in the
+Notice that we only put the declaration for the newtype @TA@ in the
@hi-boot@ file, not the signature for @f@, since @f@ isn't used by
@B@.
+The number ``1'' after ``__interface A'' gives the version number of module A;
+it is incremented whenever anything in A's interface file changes. The ``404'' is
+the version number of the interface file <em>syntax</em>; we change it when
+we change the syntax of interface files so that you get a better error message when
+you try to read an old-format file with a new-format compiler.
+
The number ``1'' at the beginning of a declaration is the <em>version
number</em> of that declaration: for the purposes of @.hi-boot@ files
these can all be set to 1. All names must be fully qualified with the
which is a module internal to GHC's prelude. It's a pain, but that's
the way it is.
+If you want an hi-boot file to export a data type, but you don't want to give its constructors
+(because the constructors aren't used by the SOURCE-importing module), you can write simply:
+
+<tscreen><verb>
+__interface A 1 404 where
+__export A TA;
+1 data TA
+</verb></tscreen>
+
+(You must write all the type parameters, but leave out the '=' and everything that follows it.)
+
<bf>Note:</bf> This is all a temporary solution, a version of the
compiler that handles mutually recursive properly without the manual
-construction of interface files, is in the works.
+construction of interface files, is (allegedly) in the works.
%************************************************************************
%* *
any running of the strictness analyser.
The options you are most likely to want to turn off are:
+<itemize>
+<item>
@-fno-strictness@<nidx>-fno-strictness option</nidx> (strictness
-analyser [because it is sometimes slow]),
+analyser, because it is sometimes slow),
+<item>
@-fno-specialise@<nidx>-fno-specialise option</nidx> (automatic
-specialisation of overloaded functions [because it makes your code
-bigger]) [US spelling also accepted], and
-@-fno-update-analysis@<nidx>-fno-update-analysis option</nidx> (update
-analyser, because it sometimes takes a <em>long</em> time). This one
-is only enabled with -O2 anyway.
+specialisation of overloaded functions, because it can make your code
+bigger) (US spelling also accepted), and
+<item>
+@-fno-cpr-analyse@<nidx>-fno-cpr-analyse option</nidx> switches off the CPR (constructed product
+result) analyser.
+</itemize>
Should you wish to turn individual flags <em>on</em>, you are advised
to use the @-Ofile@ option, described above. Because the order in
the usual C way.
</descrip>
-The @ghc@ driver pre-defines several macros:
+The @ghc@ driver pre-defines several macros when processing Haskell
+source code (@.hs@ or @.lhs@ files):
+
<descrip>
<tag>@__HASKELL98__@:</tag>
<nidx>__HASKELL98__</nidx>
-If defined, this means that GHC supports the language
-defined by the Haskell 98 report.
+If defined, this means that GHC supports the language defined by the
+Haskell 98 report.
-NB. This macro is <em/only/ set when pre-processing Haskell source
-(ie. @.hs@ or @.lhs@ files).
+<tag>@__HASKELL__=98@:</tag>
+<nidx>__HASKELL__</nidx>
+In GHC 4.04 and later, the @__HASKELL__@ macro is defined as having
+the value @98@.
<tag>@__HASKELL1__@:</tag>
<nidx>__HASKELL1__ macro</nidx>
-If defined to <em/n/, that means GHC supports the
-Haskell language defined in the Haskell report version <em/1.n/.
-Currently 5.
-
-NB. As with <tt/__HASKELL98__/, this macro is <em/only/ set when
-pre-processing Haskell source (ie. @.hs@ or @.lhs@ files).
+If defined to <em/n/, that means GHC supports the Haskell language
+defined in the Haskell report version <em/1.n/. Currently 5. This
+macro is deprecated, and will probably disappear in future versions.
<tag>@__GLASGOW_HASKELL__@:</tag>
<nidx>__GLASGOW_HASKELL__ macro</nidx>
projects / ghc-hetmet.git / blobdiff