Options can be specified in three ways:</para>
<sect2>
- <title>command-line arguments</title>
+ <title>Command-line arguments</title>
<indexterm><primary>structure, command-line</primary></indexterm>
<indexterm><primary>command-line</primary><secondary>arguments</secondary></indexterm>
ghc [argument...]
</screen>
- <para>command-line arguments are either options or file names.</para>
+ <para>Command-line arguments are either options or file names.</para>
- <para>command-line options begin with <literal>-</literal>.
+ <para>Command-line options begin with <literal>-</literal>.
They may <emphasis>not</emphasis> be grouped:
<option>-vO</option> is different from <option>-v -O</option>.
Options need not precede filenames: e.g., <literal>ghc *.o -o
</sect2>
<sect2 id="source-file-options">
- <title>command line options in source files</title>
+ <title>Command line options in source files</title>
<indexterm><primary>source-file options</primary></indexterm>
<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>
<indexterm><primary>mode</primary><secondary>options</secondary>
</indexterm>
- <para>Each of GHC's command line options is classified as either
- <firstterm>static</firstterm> or <firstterm>dynamic</firstterm> or
+ <para>Each of GHC's command line options is classified as
+ <firstterm>static</firstterm>, <firstterm>dynamic</firstterm> or
<firstterm>mode</firstterm>:</para>
<variablelist>
<term>Mode flags</term>
<listitem>
<para>For example, <option>--make</option> or <option>-E</option>.
- There may be only a single mode flag on the command line. The
+ There may only be a single mode flag on the command line. The
available modes are listed in <xref linkend="modes"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<cmdsynopsis>
+ <command>ghc --supported-languages</command>
+ </cmdsynopsis>
+ <indexterm><primary><option>––supported-languages</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Print the supported language extensions.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <cmdsynopsis>
+ <command>ghc --info</command>
+ </cmdsynopsis>
+ <indexterm><primary><option>––info</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Print information about the compiler.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <cmdsynopsis>
<command>ghc --version</command>
<command>ghc -V</command>
</cmdsynopsis>
interfaces, and include files (usually something like
<literal>/usr/local/lib/ghc-5.04</literal> on Unix). This
is the value of
- <literal>$libdir</literal><indexterm><primary><literal>libdir</literal></primary>
- </indexterm>in the package configuration file (see <xref
- linkend="packages"/>).</para>
+ <literal>$libdir</literal><indexterm><primary><literal>libdir</literal></primary></indexterm>
+ in the package configuration file
+ (see <xref linkend="packages"/>).</para>
</listitem>
</varlistentry>
<para>When given the <option>––make</option> option,
GHC will build a multi-module Haskell program by following
- dependencies from a single root module (usually
+ dependencies from one or more root modules (usually just
<literal>Main</literal>). For example, if your
<literal>Main</literal> module is in a file called
<filename>Main.hs</filename>, you could compile and link the
names or module names; GHC will figure out all the modules in
the program by following the imports from these initial modules.
It will then attempt to compile each module which is out of
- date, and finally if there is a <literal>Main</literal> module,
+ date, and finally, if there is a <literal>Main</literal> module,
the program will also be linked into an executable.</para>
<para>The main advantages to using <literal>ghc
<para>The first phase to run is determined by each input-file
suffix, and the last phase is determined by a flag. If no
- relevant flag is present, then go all the way through linking.
+ relevant flag is present, then go all the way through to linking.
This table summarises:</para>
<informaltable>
<para>Note: 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 the previous behaviour of dumping the file to
- standard output.</para>
+ of the compiler, dumping the result in a file.</para>
<sect3 id="overriding-suffixes">
<title>Overriding the default behaviour for a file</title>
<indexterm><primary>-W option</primary></indexterm>
<para>Provides the standard warnings plus
<option>-fwarn-incomplete-patterns</option>,
+ <option>-fwarn-dodgy-imports</option>,
<option>-fwarn-unused-matches</option>,
<option>-fwarn-unused-imports</option>, and
<option>-fwarn-unused-binds</option>.</para>
</varlistentry>
<varlistentry>
- <term><option>-w</option>:</term>
- <listitem>
- <indexterm><primary><option>-w</option></primary></indexterm>
- <para>Turns off all warnings, including the standard ones.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
<term><option>-Wall</option>:</term>
<listitem>
<indexterm><primary><option>-Wall</option></primary></indexterm>
<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>
+ are
+ <option>-fwarn-simple-patterns</option>,
+ <option>-fwarn-tabs</option>,
+ <option>-fwarn-incomplete-record-updates</option>,
+ <option>-fwarn-monomorphism-restriction</option>, and
+ <option>-fwarn-implicit-prelude</option>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-w</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-w</option></primary></indexterm>
+ <para>Turns off all warnings, including the standard ones and
+ those that <literal>-Wall</literal> doesn't enable.</para>
</listitem>
</varlistentry>
function or type is used. Entities can be marked as
deprecated using a pragma, see <xref
linkend="deprecated-pragma"/>.</para>
+
+ <para>This option is on by default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-fwarn-dodgy-imports</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-dodgy-imports</option></primary>
+ </indexterm>
+ <para>Causes a warning to be emitted when a a datatype
+ <literal>T</literal> is imported
+ with all constructors, i.e. <literal>T(..)</literal>, but has been
+ exported abstractly, i.e. <literal>T</literal>.</para>
</listitem>
</varlistentry>
g [] = 2
</programlisting>
- <para>This option isn't enabled be default because it can be
+ <para>This option isn't enabled by default because it can be
a bit noisy, and it doesn't always indicate a bug in the
program. However, it's generally considered good practice
to cover all the cases in your functions.</para>
f foo = foo { x = 6 }
</programlisting>
- <para>This option isn't enabled be default because it can be
+ <para>This option isn't enabled by default because it can be
very noisy, and it often doesn't indicate a bug in the
program.</para>
</listitem>
inner-scope value has the same name as an outer-scope value,
i.e. the inner value shadows the outer one. This can catch
typographical errors that turn into hard-to-find bugs, e.g.,
- in the inadvertent cyclic definition <literal>let x = ... x
- ... in</literal>.</para>
-
- <para>Consequently, this option
- <emphasis>will</emphasis> complain about cyclic recursive
- definitions.</para>
+ in the inadvertent capture of what would be a recursive call in
+ <literal>f = ... let f = id in ... f ...</literal>.</para>
</listitem>
</varlistentry>
</term>
<listitem>
<para>By default, the compiler will warn you if a set of
- patterns are overlapping, i.e.,</para>
+ patterns are overlapping, e.g.,</para>
<programlisting>
f :: String -> Int
patterns that can fail, eg. <literal>\(x:xs)->...</literal>.
Normally, these aren't treated as incomplete patterns by
<option>-fwarn-incomplete-patterns</option>.</para>
- <para>``Lambda-bound patterns'' includes all places where there is a single pattern,
+ <para>“Lambda-bound patterns” includes all places where there is a single pattern,
including list comprehensions and do-notation. In these cases, a pattern-match
failure is quite legitimate, and triggers filtering (list comprehensions) or
the monad <literal>fail</literal> operation (monads). For example:
</programlisting>
Switching on <option>-fwarn-simple-patterns</option> will elicit warnings about
these probably-innocent cases, which is why the flag is off by default. </para>
- <para> The <literal>deriving( Read )</literal> mechanism produces monadic code with
- pattern matches, so you will also get misleading warnings about the compiler-generated
- code. (This is arguably a Bad Thing, but it's awkward to fix.)</para>
-
</listitem>
</varlistentry>
the Haskell defaulting mechanism for numeric types kicks
in. This is useful information when converting code from a
context that assumed one default into one with another,
- e.g., the `default default' for Haskell 1.4 caused the
+ e.g., the ‘default default’ for Haskell 1.4 caused the
otherwise unconstrained value <constant>1</constant> to be
given the type <literal>Int</literal>, whereas Haskell 98
defaults it to <literal>Integer</literal>. This may lead to
projects / ghc-hetmet.git / blobdiff