</Para>
<Para>
-The option <Option>-E</Option><IndexTerm><Primary>-E option</Primary></IndexTerm> runs just the pre-processing
-passes of the compiler, outputting the result on stdout before
-stopping. If used in conjunction with -cpp, the output is the
+The option <Option>-E</Option><IndexTerm><Primary>-E
+option</Primary></IndexTerm> runs just the pre-processing passes of
+the compiler, dumping the result in a file. Note that this differs
+from all GHCs prior to version 4.11, in which the result was dumped to the
+standard output. If used in conjunction with -cpp, the output is the
code blocks of the original (literal) source after having put it
-through the grinder that is the C pre-processor. Sans <Option>-cpp</Option>, the
-output is the de-litted version of the original source.
+through the grinder that is the C pre-processor. Sans
+<Option>-cpp</Option>, the output is the de-litted version of the
+original source.
</Para>
<Para>
<Command>make</Command> rule for GHC compiling…
</Para>
-<Para>
-FURTHER EXOTICA: If you are doing a normal <Filename>.hs</Filename>-to-<Filename>.o</Filename> compilation
-but would like to hang onto the intermediate <Filename>.hc</Filename> C file, just
-throw in a <Option>-keep-hc-file-too</Option> option<IndexTerm><Primary>-keep-hc-file-too option</Primary></IndexTerm>.
-If you would like to look at the assembler output, toss in a
-<Option>-keep-s-file-too</Option>,<IndexTerm><Primary>-keep-s-file-too option</Primary></IndexTerm> too.
-</Para>
+ <sect2 id="keeping-intermediates">
+ <title>Keeping Intermediate Files</title>
+ <indexterm><primary>intermediate files, saving</primary>
+ </indexterm>
+ <indexterm><primary><literal>.hc</literal> files, saving</primary>
+ </indexterm>
+ <indexterm><primary><literal>.s</literal> files, saving</primary>
+ </indexterm>
+
+ <para>The following options are useful for keeping certain
+ intermediate files around, when normally GHC would throw these
+ away after compilation:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>-keep-hc-files</literal></term>
+ <indexterm>
+ <primary><literal>-keep-hc-files</literal></primary>
+ </indexterm>
+ <listitem>
+ <para>Keep intermediate <literal>.hc</literal> files when
+ doing <literal>.hs</literal>-to-<literal>.o</literal>
+ compilations via C (NOTE: <literal>.hc</literal> files
+ aren't generated when using the native code generator, you
+ may need to use <literal>-fvia-C</literal> to force them
+ to be produced).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>-keep-s-files</literal></term>
+ <indexterm>
+ <primary><literal>-keep-s-files</literal></primary>
+ </indexterm>
+ <listitem>
+ <para>Keep intermediate <literal>.s</literal> files.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>-keep-raw-s-files</literal></term>
+ <indexterm>
+ <primary><literal>-keep-raw-s-files</literal></primary>
+ </indexterm>
+ <listitem>
+ <para>Keep intermediate <literal>.raw-s</literal> files.
+ These are the direct output from the C compiler, before
+ GHC does “assembly mangling” to produce the
+ <literal>.s</literal> file. Again, these are not produced
+ when using the native code generator.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>-keep-tmp-files</literal></term>
+ <indexterm>
+ <primary><literal>-keep-tmp-files</literal></primary>
+ </indexterm>
+ <indexterm>
+ <primary>temporary files</primary>
+ <secondary>keeping</secondary>
+ </indexterm>
+ <listitem>
+ <para>Instructs the GHC driver not to delete any of its
+ temporary files, which it normally keeps in
+ <literal>/tmp</literal> (or possibly elsewhere; see <xref
+ linkend="temp-files">). Running GHC with
+ <literal>-v</literal> will show you what temporary files
+ were generated along the way.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect2>
<Sect2 id="saving-ghc-stderr">
<Title>Saving GHC's standard error output
<Title>Redirecting temporary files
</Title>
-<Para>
-<IndexTerm><Primary>temporary files, redirecting</Primary></IndexTerm>
-</Para>
+ <indexterm>
+ <primary>temporary files</primary>
+ <secondary>redirecting</secondary>
+ </indexterm>
<Para>
-If you have trouble because of running out of space in <Filename>/tmp</Filename> (or
-wherever your installation thinks temporary files should go), you may
-use the <Option>-tmpdir <dir></Option><IndexTerm><Primary>-tmpdir <dir> option</Primary></IndexTerm> option
-to specify an alternate directory. For example, <Option>-tmpdir .</Option> says to
-put temporary files in the current working directory.
+If you have trouble because of running out of space in
+<Filename>/tmp</Filename> (or wherever your installation thinks
+temporary files should go), you may use the <Option>-tmpdir
+<dir></Option><IndexTerm><Primary>-tmpdir <dir>
+option</Primary></IndexTerm> option to specify an alternate directory.
+For example, <Option>-tmpdir .</Option> says to put temporary files in
+the current working directory.
</Para>
<Para>
-Alternatively, use your <Constant>TMPDIR</Constant> environment variable.<IndexTerm><Primary>TMPDIR
-environment variable</Primary></IndexTerm> Set it to the name of the directory where
-temporary files should be put. GCC and other programs will honour the
-<Constant>TMPDIR</Constant> variable as well.
+Alternatively, use your <Constant>TMPDIR</Constant> environment
+variable.<IndexTerm><Primary>TMPDIR environment
+variable</Primary></IndexTerm> Set it to the name of the directory
+where temporary files should be put. GCC and other programs will
+honour the <Constant>TMPDIR</Constant> variable as well.
</Para>
<Para>
<Para>
<IndexTerm><Primary>-fno-implicit-prelude option</Primary></IndexTerm>
GHC normally imports <Filename>Prelude.hi</Filename> files for you. If you'd rather it
-didn't, then give it a <Option>-fno-implicit-prelude</Option> option. You are
-unlikely to get very far without a Prelude, but, hey, it's a free
-country.
+didn't, then give it a <Option>-fno-implicit-prelude</Option> option.
+The idea is that you can then import a Prelude of your own. (But don't call it <Literal>Prelude</Literal>;
+the Haskell module namespace is flat, and you must not conflict with any Prelude module.)
+</Para>
+<Para>
+Even though you have not imported the Prelude, all the built-in syntax still refers to
+the built-in Haskell Prelude types and values, as specified by the Haskell Report.
+For example, the type <Literal>[Int]</Literal>
+still means <Literal>Prelude.[] Int</Literal>; tuples continue to refer to the standard Prelude
+tuples; the translation for list comprehensions continues to use <Literal>Prelude.map</Literal> etc.
+</Para>
+<Para> With one group of exceptions! You may want to define your own numeric class hierarchy.
+It completely defeats that purpose if the literal "1" means "<Literal>Prelude.fromInteger 1</Literal>",
+which is what the Haskell Report specifies. So the <Option>-fno-implicit-prelude</Option> flag causes
+the following pieces of built-in syntax to refer to whatever is in scope, not the Prelude versions:
+<ItemizedList>
+<ListItem>
+<Para>
+Integer and fractional literals mean "<Literal>fromInteger 1</Literal>" and "<Literal>fromRational 3.2</Literal>",
+not the Prelude-qualified versions; both in expressions and in patterns.
</Para>
</ListItem>
-</VarListEntry>
-
-<VarListEntry>
-<Term><Option>-package <lib></Option></Term>
<ListItem>
<Para>
-<IndexTerm><Primary>-package <lib> option</Primary></IndexTerm>
-If you are using a system-supplied non-Prelude library (e.g., the
-POSIX library), just use a <Option>-package posix</Option> option (for
-example). The right interface files should then be available. The
-accompanying HsLibs document lists the libraries available by this
-mechanism.
+Negation (e.g. "<Literal>- (f x)</Literal>") means "<Literal>negate (f x)</Literal>" (not <Literal>Prelude.negate</Literal>).
+</Para>
+</ListItem>
+<ListItem>
+<Para>
+In an n+k pattern, the standard Prelude <Literal>Ord</Literal> class is used for comparison, but the
+necessary subtraction uses
+whatever "<Literal>(-)</Literal>" is in scope (not "<Literal>Prelude.(-)</Literal>").
+</Para>
+</ListItem>
+</ItemizedList>
</Para>
</ListItem>
</VarListEntry>
the details have changed quite a bit). <ULink URL="mailto:sansom@dcs.gla.ac.uk">Ask him</ULink> if you want a copy.
</Para>
-<Sect3 id="packages">
-<Title>Packages</Title>
-
-<Para>
-<IndexTerm><Primary>packages</Primary></IndexTerm>
-To simplify organisation and compilation, GHC keeps libraries in <Emphasis>packages</Emphasis>. Packages are also compiled into single libraries on Unix, and DLLs on Windows. The term ``package'' can be used pretty much synonymously with ``library'', except that an application also forms a package, the Main package.
-</Para>
-
-<ItemizedList>
-<ListItem>
-<Para>
-A package is a group of modules. It may span many directories, or many packages may exist in a single directory. Packages may not be mutually recursive.
-</Para>
-</ListItem>
-
-<ListItem>
-<Para>
-A package has a name (e.g. <Filename>std</Filename>)
-</Para>
-</ListItem>
-
-<ListItem>
-<Para>
-Each package is built into a single library (Unix; e.g. <Filename>libHSfoo.a</Filename>), or a single DLL (Windows; e.g. <Filename>HSfoo.dll</Filename>)
-</Para>
-</ListItem>
-
-<ListItem>
-<Para>
-The <Option>-package-name foo</Option> flag tells GHC that the module being compiled is destined for package <Filename>foo</Filename>. If this is omitted, the default package, <Filename>Main</Filename>, is assumed.
-</Para>
-</ListItem>
-
-<ListItem>
-<Para>
-The <Option>-package foo</Option> flag tells GHC to make available modules
-from package <Filename>foo</Filename>. It replaces <Option>-syslib foo</Option>, which is now deprecated.
-</Para>
-</ListItem>
-
-<ListItem>
-<Para>
-GHC does not maintain detailed cross-package dependency information.
-It does remember which modules in other packages the current module
-depends on, but not which things within those imported things.
-</Para>
-</ListItem>
-</ItemizedList>
-
-<Para>
-All of this tidies up the Prelude enormously. The Prelude and
-Standard Libraries are built into a single package called <Filename>std</Filename>. (This
-is a change; the library is now called <Filename>libHSstd.a</Filename> instead of <Filename>libHS.a</Filename>).
-</Para>
-
-<Para>
-It is worth noting that on Windows, because each package is built as a DLL, and a reference to a DLL costs an extra indirection, intra-package references are cheaper than inter-package references. Of course, this applies to the <Filename>Main</Filename> package as well. This is not normally the case on most Unices.
-</Para>
-
-</Sect3>
-
</Sect2>
</Sect1>
+ <sect1 id="packages">
+ <title>Packages</title>
+ <indexterm><primary>packages</primary></indexterm>
+
+ <para>Packages are collections of libraries, conveniently grouped
+ together as a single entity. The package system is flexible: a
+ package may consist of Haskell code, foreign language code (eg. C
+ libraries), or a mixture of the two. A package is a good way to
+ group together related Haskell modules, and is essential if you
+ intend to make the modules into a Windows DLL (see below).</para>
+
+ <para>Because packages can contain both Haskell and C libraries, they
+ are also a good way to provide convenient access to a Haskell
+ layer over a C library.</para>
+
+ <para>GHC comes with several packages (see <xref
+ linkend="book-hslibs">), and packages can be added/removed from an
+ existing GHC installation.</para>
+
+ <sect2 id="listing-packages">
+ <title>Listing the available packages</title>
+ <indexterm><primary>packages</primary>
+ <secondary>listing</secondary></indexterm>
+
+ <para>To see what packages are currently installed, use the
+ <literal>--list-packages</literal> option:</para>
+ <indexterm><primary><literal>--list-packages</literal></primary>
+ </indexterm>
+
+<screen>
+ $ ghc --list-packages
+ gmp, rts, std, lang, concurrent, data, net, posix, text, util
+</screen>
+
+ <para>Note that your GHC installation might have a slightly
+ different set of packages installed.</para>
+
+ <para>The <literal>gmp</literal> and <literal>rts</literal>
+ packages are always present, and represent the multi-precision
+ integer and runtime system libraries respectively. The
+ <literal>std</literal> package contains the Haskell prelude.
+ The rest of the packages are optional libraries.</para>
+
+ </sect2>
+
+ <sect2 id="using-packages">
+ <title>Using a package</title>
+ <indexterm><primary>packages</primary>
+ <secondary>using</secondary></indexterm>
+
+ <para>To use a package, add the <literal>-package</literal> flag
+ to the command line:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>-package <lib></option></term>
+ <indexterm><primary>-package <lib> option</primary></indexterm>
+ <listitem>
+ <para>This option brings into scope all the modules from
+ package <literal><lib></literal> (they still have to
+ be imported in your Haskell source, however). It also
+ causes the relevant libraries to be linked when linking is
+ being done.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Some packages depend on other packages, for example the
+ <literal>text</literal> package makes use of some of the modules
+ in the <literal>lang</literal> package. The package system
+ takes care of all these dependencies, so that when you say
+ <literal>-package text</literal> on the command line, you
+ automatically get <literal>-package lang</literal> too.</para>
+ </sect2>
+
+ <sect2 id="building-packages">
+ <title>Building a package from Haskell source</title>
+ <indexterm><primary>packages</primary>
+ <secondary>building</secondary></indexterm>
+
+ <para>It takes some special considerations to build a new
+ package:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>A package may contain several Haskell modules. A
+ package may span many directories, or many packages may
+ exist in a single directory. Packages may not be mutually
+ recursive.</para>
+ </listitem>
+
+ <listitem>
+ <para>A package has a name
+ (e.g. <filename>std</filename>)</para>
+ </listitem>
+
+ <listitem>
+ <para>The Haskell code in a package may be built into one or
+ more Unix libraries (e.g. <Filename>libHSfoo.a</Filename>),
+ or a single DLL on Windows
+ (e.g. <Filename>HSfoo.dll</Filename>). The restriction to a
+ single DLL on Windows is that the package system is used to
+ tell the compiler when it should make an inter-DLL call
+ rather than an intra-DLL call (inter-DLL calls require an
+ extra indirection).</para>
+ </listitem>
+
+ <listitem>
+ <para>GHC does not maintain detailed cross-package
+ dependency information. It does remember which modules in
+ other packages the current module depends on, but not which
+ things within those imported things.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>To compile a module which is to be part of a new package,
+ use the <literal>-package-name</literal> option:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>-package-name <foo></option></term>
+ <indexterm><primary><literal>-package-name</literal></primary>
+ <secondary>option</secondary></indexterm>
+ <listitem>
+ <para>This option is added to the command line when
+ compiling a module that is destined to be part of package
+ <literal>foo</literal>. If this flag is omitted then the
+ default package <literal>Main</literal> is assumed.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>Failure to use the <literal>-package-name</literal> option
+ when compiling a package will result in disaster on Windows, but
+ is relatively harmless on Unix at the moment (it will just cause
+ a few extra dependencies in some interface files). However,
+ bear in mind that we might add support for Unix shared libraries
+ at some point in the future.</para>
+
+ <para>It is worth noting that on Windows, because each package
+ is built as a DLL, and a reference to a DLL costs an extra
+ indirection, intra-package references are cheaper than
+ inter-package references. Of course, this applies to the
+ <Filename>Main</Filename> package as well.</para>
+
+ </sect2>
+ <sect2 id="package-management">
+ <title>Package management</title>
+ <indexterm><primary>packages</primary>
+ <secondary>management</secondary></indexterm>
+
+ <para>GHC uses a package configuration file, called
+ <literal>packages.conf</literal>, which can be found in your GHC
+ install directory. This file isn't intended to be edited
+ directly, instead GHC provides options for adding & removing
+ packages:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>--add-package</option></term>
+ <indexterm><primary><literal>--add-package</literal></primary>
+ <secondary>option</secondary></indexterm>
+ <listitem>
+ <para>Reads a package specification (see below) on stdin,
+ and adds it to the database of installed packages. The
+ package specification must be a package that isn't already
+ installed.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>--delete-package <foo></option></term>
+ <indexterm><primary><literal>--delete-package</literal></primary>
+ <secondary>option</secondary></indexterm>
+ <listitem>
+ <para>Removes the specified package from the installed
+ configuration.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>In both cases, the old package configuration file is saved
+ in <literal>packages.conf.old</literal> in your GHC install
+ directory, so in an emergency you can always copy this file into
+ <literal>package.conf</literal> to restore the old
+ settings.</para>
+
+ <para>A package specification looks like this:</para>
+
+<screen>
+ Package {
+ name = "mypkg",
+ import_dirs = ["/usr/local/lib/imports/mypkg"],
+ library_dirs = ["/usr/local/lib"],
+ hs_libraries = ["HSmypkg" ],
+ extra_libraries = ["HSmypkg_cbits"],
+ include_dirs = [],
+ c_includes = ["HsMyPkg.h"],
+ package_deps = ["text", "data"],
+ extra_ghc_opts = [],
+ extra_cc_opts = [],
+ extra_ld_opts = ["-lmy_clib"]
+ }
+</screen>
+
+ <para>Components of a package specification may be specified in
+ any order, and are:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>name</literal></term>
+ <indexterm><primary><literal>name</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>The package's name, for use with
+ the <literal>-package</literal> flag and as listed in the
+ <literal>--list-packages</literal> list.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>import_dirs</literal></term>
+ <indexterm><primary><literal>import_dirs</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of directories containing interface files
+ (<literal>.hi</literal> files) for this package.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>library_dirs</literal></term>
+ <indexterm><primary><literal>library_dirs</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of directories containing libraries for this
+ package.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>hs_libraries</literal></term>
+ <indexterm><primary><literal>hs_libraries</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of libraries containing Haskell code for this
+ package, with the <literal>.a</literal> or
+ <literal>.dll</literal> suffix omitted. On Unix, the
+ <literal>lib</literal> prefix is also omitted.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>extra_libraries</literal></term>
+ <indexterm><primary><literal>extra_libraries</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of extra libraries for this package. The
+ difference between <literal>hs_libraries</literal> and
+ <literal>extra_libraries</literal> is that
+ <literal>hs_libraries</literal> normally have several
+ versions, to support profiling, parallel and other build
+ options. The various versions are given different
+ suffixes to distinguish them, for example the profiling
+ version of the standard prelude library is named
+ <filename>libHSstd_p.a</filename>, with the
+ <literal>_p</literal> indicating that this is a profiling
+ version. The suffix is added automatically by GHC for
+ <literal>hs_libraries</literal> only, no suffix is added
+ for libraries in
+ <literal>extra_libraries</literal>.</para>
+
+ <para>Also, <literal>extra_libraries</literal> are placed
+ on the linker command line before the
+ <literal>hs_libraries</literal> for the same package. If
+ your package has dependencies in the other direction, you
+ might need to make two separate packages.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>include_dirs</literal></term>
+ <indexterm><primary><literal>include_dirs</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of directories containing C includes for this
+ package (maybe the empty list).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>c_includes</literal></term>
+ <indexterm><primary><literal>c_includes</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of files to include for via-C compilations
+ using this package. Typically this include file will
+ contain function prototypes for any C functions used in
+ the package, in case they end up being called as a result
+ of Haskell functions from the package being
+ inlined.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>package_deps</literal></term>
+ <indexterm><primary><literal>package_deps</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>A list of packages which this package depends
+ on.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>extra_ghc_opts</literal></term>
+ <indexterm><primary><literal>extra_ghc_opts</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>Extra arguments to be added to the GHC command line
+ when this package is being used.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>extra_cc_opts</literal></term>
+ <indexterm><primary><literal>extra_cc_opts</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>Extra arguments to be added to the gcc command line
+ when this package is being used (only for via-C
+ compilations).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>extra_ld_opts</literal></term>
+ <indexterm><primary><literal>extra_ld_opts</literal></primary>
+ <secondary>package specification</secondary></indexterm>
+ <listitem>
+ <para>Extra arguments to be added to the gcc command line
+ (for linking) when this package is being used.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>For examples of more package specifications, take a look
+ at the <literal>package.conf</literal> in your GHC
+ installation.</para>
+ </sect2>
+ </sect1>
+
+
<Sect1 id="options-optimise">
<Title>Optimisation (code improvement)
</Title>
</Para>
</ListItem>
</VarListEntry>
+
<VarListEntry>
-<Term><Option>-funfolding-con-discount<n></Option>:</Term>
+<Term><Option>-funfolding-update-in-place<n></Option>:</Term>
<ListItem>
<Para>
-<IndexTerm><Primary>-funfolding-con-discount option</Primary></IndexTerm>
-<IndexTerm><Primary>inlining, controlling</Primary></IndexTerm>
-<IndexTerm><Primary>unfolding, controlling</Primary></IndexTerm>
-(Default: 2) If the compiler decides that it can eliminate some
-computation by performing an unfolding, then this is a discount factor
-that it applies to the funciton size before deciding whether to unfold
-it or not.
-</Para>
-
-<Para>
-OK, folks, these magic numbers `30', `8', and '2' are mildly
-arbitrary; they are of the “seem to be OK” variety. The `8' is the
-more critical one; it's what determines how eager GHC is about
-expanding unfoldings.
+Switches on an experimental "optimisation". Switching it on makes the compiler
+a little keener to inline a function that returns a constructor, if the context is
+that of a thunk.
+<ProgramListing>
+ x = plusInt a b
+</ProgramListing>
+If we inlined plusInt we might get an opportunity to use update-in-place for
+the thunk 'x'.
</Para>
</ListItem>
</VarListEntry>
+
<VarListEntry>
<Term><Option>-funbox-strict-fields</Option>:</Term>
<ListItem>
</Para>
</ListItem>
</VarListEntry>
+<VarListEntry>
+<Term><Option>-fexcess-precision</Option>:</Term>
+<ListItem>
+<Para>
+When this option is given, intermediate floating point values can have
+a <Emphasis>greater</Emphasis> precision/range than the final type.
+Generally this is a good thing, but some programs may rely on the
+exact precision/range of <Literal>Float</Literal>/<Literal>Double</Literal>
+values and should not use this option for their compilation.
+</Para>
+</ListItem>
+</VarListEntry>
</VariableList>
</Para>
</Para>
<Para>
-If you are using a Haskell “system library” (e.g., the POSIX
-library), just use the <Option>-package posix</Option> option, and the correct code
-should be linked in.
+If you are using a Haskell “package” (e.g., the POSIX
+library), just use the <Option>-package posix</Option> option, and the
+correct code should be linked in. See <xref linkend="packages"> for
+more details.
</Para>
</ListItem>
</VarListEntry>
<Term><Option>-C[<us>]</Option>:</Term>
<ListItem>
<Para>
-<IndexTerm><Primary>-C<us> RTS option</Primary></IndexTerm>
-Sets the context switch interval to <Literal><us></Literal> microseconds. A context
-switch will occur at the next heap allocation after the timer expires.
-With <Option>-C0</Option> or <Option>-C</Option>, context switches will occur as often as
-possible (at every heap allocation). By default, context switches
-occur every 10 milliseconds. Note that many interval timers are only
-capable of 10 millisecond granularity, so the default setting may be
-the finest granularity possible, short of a context switch at every
-heap allocation.
-</Para>
-
-<Para>
-[NOTE: this option currently has no effect (version 4.00). Context
-switches happen when the current heap block is full, i.e. every 4k of
-allocation].
+<IndexTerm><Primary>-C<us> RTS option</Primary></IndexTerm> Sets
+the context switch interval to <Literal><s></Literal> seconds.
+A context switch will occur at the next heap block allocation after
+the timer expires (a heap block allocation occurs every 4k of
+allocation). With <Option>-C0</Option> or <Option>-C</Option>,
+context switches will occur as often as possible (at every heap block
+allocation). By default, context switches occur every 20ms
+milliseconds. Note that GHC's internal timer ticks every 20ms, and
+the context switch timer is always a multiple of this timer, so 20ms
+is the maximum granularity available for timed context switches.
</Para>
</ListItem>
</VarListEntry>
projects / ghc-hetmet.git / blobdiff