<para>It is not recommended to move all the contents of your
Makefiles into your source files, but in some circumstances, the
<literal>OPTIONS_GHC</literal> pragma is the Right Thing. (If you
- use <option>-keep-hc-file-too</option> and have OPTION flags in
+ use <option>-keep-hc-file</option> and have OPTION flags in
your module, the OPTIONS_GHC will get put into the generated .hc
file).</para>
</sect2>
<para>Dependency-generation mode. In this mode, GHC can be
used to generate dependency information suitable for use in
a <literal>Makefile</literal>. See <xref
- linkend="sec-makefile-dependencies"/>.</para>
+ linkend="makefile-dependencies"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<cmdsynopsis>
- <command>ghc --version</command> <command>ghc -V</command>
+ <command>ghc --version</command>
+ <command>ghc -V</command>
+ </cmdsynopsis>
<indexterm><primary><option>-V</option></primary></indexterm>
<indexterm><primary><option>––version</option></primary></indexterm>
- </cmdsynopsis>
</term>
<listitem>
<para>Print a one-line string including GHC's version number.</para>
<varlistentry>
<term>
<cmdsynopsis>
- <command>ghc --numeric-version</command>
+ <command>ghc --numeric-version</command>
+ </cmdsynopsis>
<indexterm><primary><option>––numeric-version</option></primary></indexterm>
- </cmdsynopsis>
</term>
<listitem>
<para>Print GHC's numeric version number only.</para>
<varlistentry>
<term>
<cmdsynopsis>
- <command>ghc --print-libdir</command>
+ <command>ghc --print-libdir</command>
+ </cmdsynopsis>
<indexterm><primary><option>––print-libdir</option></primary></indexterm>
- </cmdsynopsis>
</term>
<listitem>
<para>Print the path to GHC's library directory. This is
<indexterm><primary>help options</primary></indexterm>
<indexterm><primary>verbosity options</primary></indexterm>
- See also the <option>--help</option>, <option>--version</option>, <option>--numeric-version</option>,
- and <option>--print-libdir</option> modes in <xref linkend="modes"/>.
+ <para>See also the <option>--help</option>, <option>--version</option>, <option>--numeric-version</option>,
+ and <option>--print-libdir</option> modes in <xref linkend="modes"/>.</para>
<variablelist>
<varlistentry>
<term>
<term><option>-Wall</option>:</term>
<listitem>
<indexterm><primary><option>-Wall</option></primary></indexterm>
- <para>Turns on all warning options.</para>
+ <para>Turns on all warning options that indicate potentially
+ suspicious code. The warnings that are
+ <emphasis>not</emphasis> enabled by <option>-Wall</option>
+ are:</para>
+ <itemizedlist>
+ <listitem><option>-fwarn-simple-patterns</option></listitem>
+ <listitem><option>-fwarn-tabs</option></listitem>
+ <listitem><option>-fwarn-incomplete-record-updates</option></listitem>
+ <listitem><option>-fwarn-monomorphism-restriction</option></listitem>
+ <listitem><option>-fwarn-implicit-prelude</option></listitem>
+ </itemizedlist>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-implicit-prelude</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-implicit-prelude</option></primary></indexterm>
+ <indexterm><primary>implicit prelude, warning</primary></indexterm>
+ <para>Have the compiler warn if the Prelude is implicitly
+ imported. This happens unless either the Prelude module is
+ explicitly imported with an <literal>import ... Prelude ...</literal>
+ line, or this implicit import is disabled (either by
+ <option>-fno-implicit-prelude</option> or a
+ <literal>LANGUAGE NoImplicitPrelude</literal> pragma).</para>
+
+ <para>Note that no warning is given for syntax that implicitly
+ refers to the Prelude, even if <option>-fno-implicit-prelude</option>
+ would change whether it refers to the Prelude.
+ For example, no warning is given when
+ <literal>368</literal> means
+ <literal>Prelude.fromInteger (368::Prelude.Integer)</literal>
+ (where <literal>Prelude</literal> refers to the actual Prelude module,
+ regardless of the imports of the module being compiled).</para>
+
+ <para>This warning is off by default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-incomplete-patterns</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-incomplete-patterns</option></primary></indexterm>
<para>If you would like GHC to check that every top-level
function/value has a type signature, use the
- <option>-fwarn-missing-signatures</option> option. This
+ <option>-fwarn-missing-signatures</option> option. As part of
+ the warning GHC also reports the inferred type. The
option is off by default.</para>
</listitem>
</varlistentry>
in the inadvertent cyclic definition <literal>let x = ... x
... in</literal>.</para>
- <para>Consequently, this option does
+ <para>Consequently, this option
<emphasis>will</emphasis> complain about cyclic recursive
definitions.</para>
</listitem>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-monomorphism-restriction</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-monomorphism-restriction</option></primary></indexterm>
+ <indexterm><primary>monomorphism restriction, warning</primary></indexterm>
+ <para>Have the compiler warn/inform you where in your source
+ the Haskell Monomorphism Restriction is applied. If applied silently
+ the MR can give rise to unexpected behaviour, so it can be helpful
+ to have an explicit warning that it is being applied.</para>
+
+ <para>This warning is off by default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-unused-binds</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-unused-binds</option></primary></indexterm>
<para>Note that higher optimisation levels cause more
cross-module optimisation to be performed, which can have an
impact on how much of your program needs to be recompiled when
- you change something. This is one reaosn to stick to
+ you change something. This is one reason to stick to
no-optimisation when developing code.</para>
<variablelist>
<literal>Exception.assert</literal> in source code (in
other words, rewriting <literal>Exception.assert p
e</literal> to <literal>e</literal> (see <xref
- linkend="sec-assertions"/>). This flag is turned on by
+ linkend="assertions"/>). This flag is turned on by
<option>-O</option>.
</para>
</listitem>
<varlistentry>
<term>
+ <option>-fno-state-hack</option>
+ <indexterm><primary><option>-fno-state-hack</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turn off the "state hack" whereby any lambda with a
+ <literal>State#</literal> token as argument is considered to be
+ single-entry, hence it is considered OK to inline things inside
+ it. This can improve performance of IO and ST monad code, but it
+ runs the risk of reducing sharing.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fomit-interface-pragmas</option>
+ <indexterm><primary><option>-fomit-interface-pragmas</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Tells GHC to omit all inessential information from the interface file
+ generated for the module being compiled (say M). This means that a module
+ importing M will see only the <emphasis>types</emphasis> of the functions that M exports, but not
+ their unfoldings, strictness info, etc. Hence, for example,
+ no function exported by M will be inlined
+ into an importing module. The benefit is that modules that import M will
+ need to be recompiled less often (only when M's exports change their type,
+ not when they change their implementation).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fignore-interface-pragmas</option>
+ <indexterm><primary><option>-fignore-interface-pragmas</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Tells GHC to ignore all inessential information when reading interface files.
+ That is, even if <filename>M.hi</filename> contains unfolding or strictness information
+ for a function, GHC will ignore that information.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<option>-funbox-strict-fields</option>:
<indexterm><primary><option>-funbox-strict-fields</option></primary></indexterm>
<indexterm><primary>strict constructor fields</primary></indexterm>
<varlistentry>
<term>
- <option>-funfolding-update-in-place<n></option>
+ <option>-funfolding-update-in-place=<replaceable>n</replaceable></option>
<indexterm><primary><option>-funfolding-update-in-place</option></primary></indexterm>
</term>
<listitem>
<varlistentry>
<term>
- <option>-funfolding-creation-threshold<n></option>:
+ <option>-funfolding-creation-threshold=<replaceable>n</replaceable></option>:
<indexterm><primary><option>-funfolding-creation-threshold</option></primary></indexterm>
<indexterm><primary>inlining, controlling</primary></indexterm>
<indexterm><primary>unfolding, controlling</primary></indexterm>
</varlistentry>
<varlistentry>
- <term><option>-funfolding-use-threshold<n></option>:</term>
+ <term><option>-funfolding-use-threshold=<replaceable>n</replaceable></option></term>
<listitem>
<indexterm><primary><option>-funfolding-use-threshold</option></primary></indexterm>
<indexterm><primary>inlining, controlling</primary></indexterm>
&phases;
- <sect1 id="sec-using-concurrent">
+ <sect1 id="using-concurrent">
<title>Using Concurrent Haskell</title>
<indexterm><primary>Concurrent Haskell</primary><secondary>using</secondary></indexterm>
</variablelist>
</sect1>
- <sect1 id="sec-using-smp">
+ <sect1 id="using-smp">
<title>Using SMP parallelism</title>
<indexterm><primary>parallelism</primary>
</indexterm>
projects / ghc-hetmet.git / blobdiff