permitted. Leaving out all of them gives you standard Haskell
98.</para>
- <para>Generally speaking, all the language options are introduced by "<option>-X</option>" or "<option>-X=</option>";
- e.g. <option>-X=TemplateHaskell</option>. Before anything else is done, the string following
- "<option>-X</option>" is normalised by removing hyphens and converting
- to lower case. So <option>-X=TemplateHaskell</option>, <option>-XTemplateHaskell</option>, and
- <option>-Xtemplate-haskell</option> are all equivalent.
+ <para>Generally speaking, all the language options are introduced by "<option>-X</option>",
+ e.g. <option>-XTemplateHaskell</option>.
</para>
<para> All the language options can be turned off by using the prefix "<option>No</option>";
- e.g. "<option>-X=NoTemplateHaskell</option>".</para>
+ e.g. "<option>-XNoTemplateHaskell</option>".</para>
<para> Language options recognised by Cabal can also be enabled using the <literal>LANGUAGE</literal> pragma,
thus <literal>{-# LANGUAGE TemplateHaskell #-}</literal> (see <xref linkend="language-pragma"/>>). </para>
- <para> All the language options can be introduced with "<option>-f</option>" as well as "<option>-X</option>",
- but this is a deprecated feature for backward compatibility. Use the "<option>-X</option>"
- or LANGUAGE-pragma form.</para>
-
<para>Turning on an option that enables special syntax
<emphasis>might</emphasis> cause working Haskell 98 code to fail
to compile, perhaps because it uses a variable name which has
<literal>|)</literal>, <literal>{|</literal>.</para>
<para>Implies these specific language options:
- <option>-X=ForeignFunctionInterface</option>,
- <option>-X=ImplicitParams</option>,
- <option>-X=ScopedTypeVariables</option>,
- <option>-X=GADTs</option>,
- <option>-X=TypeFamilies</option>. </para>
+ <option>-XForeignFunctionInterface</option>,
+ <option>-XImplicitParams</option>,
+ <option>-XScopedTypeVariables</option>,
+ <option>-XGADTs</option>,
+ <option>-XTypeFamilies</option>. </para>
</listitem>
</varlistentry>
<varlistentry>
<term>
- <option>-X=ffi</option> and <option>-X=ForeignFunctionInterface</option>:
- <indexterm><primary><option>-X=FFI</option></primary></indexterm>
+ <option>-XForeignFunctionInterface</option>:
+ <indexterm><primary><option>-XForeignFunctionInterface</option></primary></indexterm>
</term>
<listitem>
<para>This option enables the language extension defined in the
<varlistentry>
<term>
- <option>-X=MonomorphismRestriction</option>,<option>-X=MonoPatBinds</option>:
+ <option>-XMonomorphismRestriction</option>,<option>-XMonoPatBinds</option>:
</term>
<listitem>
<para> These two flags control how generalisation is done.
<varlistentry>
<term>
- <option>-X=ExtendedDefaultRules</option>:
- <indexterm><primary><option>-X=ExtendedDefaultRules</option></primary></indexterm>
+ <option>-XExtendedDefaultRules</option>:
+ <indexterm><primary><option>-XExtendedDefaultRules</option></primary></indexterm>
</term>
<listitem>
<para> Use GHCi's extended default rules in a regular module (<xref linkend="extended-default-rules"/>).
<varlistentry>
<term>
- <option>-X=AllowOverlappingInstances</option>
- <indexterm><primary><option>-X=AllowOverlappingInstances</option></primary></indexterm>
+ <option>-XOverlappingInstances</option>
+ <indexterm><primary><option>-XOverlappingInstances</option></primary></indexterm>
</term>
<term>
- <option>-X=AllowUndecidableInstances</option>
- <indexterm><primary><option>-X=AllowUndecidableInstances</option></primary></indexterm>
+ <option>-XUndecidableInstances</option>
+ <indexterm><primary><option>-XUndecidableInstances</option></primary></indexterm>
</term>
<term>
- <option>-X=AllowIncoherentInstances</option>
- <indexterm><primary><option>-X=AllowIncoherentInstances</option></primary></indexterm>
+ <option>-XIncoherentInstances</option>
+ <indexterm><primary><option>-XIncoherentInstances</option></primary></indexterm>
</term>
<term>
<option>-fcontext-stack=N</option>
<varlistentry>
<term>
- <option>-X=Arrows</option>
- <indexterm><primary><option>-X=Arrows</option></primary></indexterm>
+ <option>-XArrows</option>
+ <indexterm><primary><option>-XArrows</option></primary></indexterm>
</term>
<listitem>
<para>See <xref linkend="arrow-notation"/>. Independent of
<varlistentry>
<term>
- <option>-X=Generics</option>
- <indexterm><primary><option>-X=Generics</option></primary></indexterm>
+ <option>-XGenerics</option>
+ <indexterm><primary><option>-XGenerics</option></primary></indexterm>
</term>
<listitem>
<para>See <xref linkend="generic-classes"/>. Independent of
</varlistentry>
<varlistentry>
- <term><option>-X=NoImplicitIrelude</option></term>
+ <term><option>-XNoImplicitPrelude</option></term>
<listitem>
- <para><indexterm><primary>-XnoImplicitPrelude
+ <para><indexterm><primary>-XNoImplicitPrelude
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>-XnoImplicitPrelude</option> option. The idea is
+ <option>-XNoImplicitPrelude</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
translation for list comprehensions continues to use
<literal>Prelude.map</literal> etc.</para>
- <para>However, <option>-X=NoImplicitPrelude</option> does
+ <para>However, <option>-XNoImplicitPrelude</option> does
change the handling of certain built-in syntax: see <xref
linkend="rebindable-syntax"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-X=ImplicitParams</option></term>
+ <term><option>-XImplicitParams</option></term>
<listitem>
<para>Enables implicit parameters (see <xref
linkend="implicit-parameters"/>). Currently also implied by
</varlistentry>
<varlistentry>
- <term><option>-X=OverloadedStrings</option></term>
+ <term><option>-XOverloadedStrings</option></term>
<listitem>
<para>Enables overloaded string literals (see <xref
linkend="overloaded-strings"/>).</para>
</varlistentry>
<varlistentry>
- <term><option>-X=ScopedTypeVariables</option></term>
+ <term><option>-XScopedTypeVariables</option></term>
<listitem>
<para>Enables lexically-scoped type variables (see <xref
linkend="scoped-type-variables"/>). Implied by
</varlistentry>
<varlistentry>
- <term><option>-X=TH</option>, <option>-X=TemplateHaskell</option></term>
+ <term><option>-XTemplateHaskell</option></term>
<listitem>
<para>Enables Template Haskell (see <xref
linkend="template-haskell"/>). This flag must
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>-X=NoImplicitPrelude</option> flag causes
+ So the <option>-XNoImplicitPrelude</option> flag causes
the following pieces of built-in syntax to refer to
<emphasis>whatever is in scope</emphasis>, not the Prelude
versions:
</para>
<para>
The rest of this section outlines the extensions to GHC that support GADTs. The extension is enabled with
-<option>-X=GADTs</option>.
+<option>-XGADTs</option>.
<itemizedlist>
<listitem><para>
A GADT can only be declared using GADT-style syntax (<xref linkend="gadt-style"/>);
</para>
<para>
Nevertheless, GHC allows you to experiment with more liberal rules. If you use
-the experimental flag <option>-X=AllowUndecidableInstances</option>
-<indexterm><primary>-X=AllowUndecidableInstances</primary></indexterm>,
+the experimental flag <option>-XUndecidableInstances</option>
+<indexterm><primary>-XUndecidableInstances</primary></indexterm>,
both the Paterson Conditions and the Coverage Condition
(described in <xref linkend="instance-rules"/>) are lifted. Termination is ensured by having a
fixed-depth recursion stack. If you exceed the stack depth you get a
In general, <emphasis>GHC requires that that it be unambiguous which instance
declaration
should be used to resolve a type-class constraint</emphasis>. This behaviour
-can be modified by two flags: <option>-X=AllowOverlappingInstances</option>
-<indexterm><primary>-X=AllowOverlappingInstances
+can be modified by two flags: <option>-XOverlappingInstances</option>
+<indexterm><primary>-XOverlappingInstances
</primary></indexterm>
-and <option>-X=AllowIncoherentInstances</option>
-<indexterm><primary>-X=AllowIncoherentInstances
+and <option>-XIncoherentInstances</option>
+<indexterm><primary>-XIncoherentInstances
</primary></indexterm>, as this section discusses. Both these
flags are dynamic flags, and can be set on a per-module basis, using
an <literal>OPTIONS_GHC</literal> pragma if desired (<xref linkend="source-file-options"/>).</para>
</para>
<para>
-The <option>-X=AllowOverlappingInstances</option> flag instructs GHC to allow
+The <option>-XOverlappingInstances</option> flag instructs GHC to allow
more than one instance to match, provided there is a most specific one. For
example, the constraint <literal>C Int [Int]</literal> matches instances (A),
(C) and (D), but the last is more specific, and hence is chosen. If there is no
GHC does not commit to instance (C), because in a particular
call of <literal>f</literal>, <literal>b</literal> might be instantiate
to <literal>Int</literal>, in which case instance (D) would be more specific still.
-So GHC rejects the program. If you add the flag <option>-X=AllowIncoherentInstances</option>,
+So GHC rejects the program. If you add the flag <option>-XIncoherentInstances</option>,
GHC will instead pick (C), without complaining about
the problem of subsequent instantiations.
</para>
<para>
The willingness to be overlapped or incoherent is a property of
the <emphasis>instance declaration</emphasis> itself, controlled by the
-presence or otherwise of the <option>-X=AllowOverlappingInstances</option>
-and <option>-X=AllowIncoherentInstances</option> flags when that mdodule is
+presence or otherwise of the <option>-XOverlappingInstances</option>
+and <option>-XIncoherentInstances</option> flags when that mdodule is
being defined. Neither flag is required in a module that imports and uses the
instance declaration. Specifically, during the lookup process:
<itemizedlist>
<listitem><para>
An instance declaration is ignored during the lookup process if (a) a more specific
match is found, and (b) the instance declaration was compiled with
-<option>-X=AllowOverlappingInstances</option>. The flag setting for the
+<option>-XOverlappingInstances</option>. The flag setting for the
more-specific instance does not matter.
</para></listitem>
<listitem><para>
does unify with it, so that it might match when the constraint is further
instantiated. Usually GHC will regard this as a reason for not committing to
some other constraint. But if the instance declaration was compiled with
-<option>-X=AllowIncoherentInstances</option>, GHC will skip the "does-it-unify?"
+<option>-XIncoherentInstances</option>, GHC will skip the "does-it-unify?"
check for that declaration.
</para></listitem>
</itemizedlist>
</para>
<para>
If an instance declaration is compiled without
-<option>-X=AllowOverlappingInstances</option>,
+<option>-XOverlappingInstances</option>,
then that instance can never be overlapped. This could perhaps be
inconvenient. Perhaps the rule should instead say that the
<emphasis>overlapping</emphasis> instance declaration should be compiled in
this way, rather than the <emphasis>overlapped</emphasis> one. Perhaps overlap
at a usage site should be permitted regardless of how the instance declarations
-are compiled, if the <option>-X=AllowOverlappingInstances</option> flag is
+are compiled, if the <option>-XOverlappingInstances</option> flag is
used at the usage site. (Mind you, the exact usage site can occasionally be
hard to pin down.) We are interested to receive feedback on these points.
</para>
-<para>The <option>-X=AllowIncoherentInstances</option> flag implies the
-<option>-X=AllowOverlappingInstances</option> flag, but not vice versa.
+<para>The <option>-XIncoherentInstances</option> flag implies the
+<option>-XOverlappingInstances</option> flag, but not vice versa.
</para>
</sect3>
due to Jeff Lewis.)</para>
<para>Implicit parameter support is enabled with the option
-<option>-X=ImplicitParams</option>.</para>
+<option>-XImplicitParams</option>.</para>
<para>
A variable is called <emphasis>dynamically bound</emphasis> when it is bound by the calling
<para>Following a suggestion of Mark Jones, in his paper
<ulink url="http://www.cse.ogi.edu/~mpj/thih/">Typing Haskell in
Haskell</ulink>,
-GHC implements a more general scheme. If <option>-X=RelaxedPolyRec</option> is
+GHC implements a more general scheme. If <option>-XRelaxedPolyRec</option> is
specified:
<emphasis>the dependency analysis ignores references to variables that have an explicit
type signature</emphasis>.
The same refined dependency analysis also allows the type signatures of
mutually-recursive functions to have different contexts, something that is illegal in
Haskell 98 (Section 4.5.2, last sentence). With
-<option>-X=RelaxedPolyRec</option>
+<option>-XRelaxedPolyRec</option>
GHC only insists that the type signatures of a <emphasis>refined</emphasis> group have identical
type signatures; in practice this means that only variables bound by the same
pattern binding must have the same context. For example, this is fine:
<para>
GHC supports <emphasis>overloaded string literals</emphasis>. Normally a
string literal has type <literal>String</literal>, but with overloaded string
-literals enabled (with <literal>-X=OverloadedStrings</literal>)
+literals enabled (with <literal>-XOverloadedStrings</literal>)
a string literal has type <literal>(IsString a) => a</literal>.
</para>
<para>
from module <literal>GHC.Exts</literal>.
</para>
<para>
-Haskell's defaulting mechanism is extended to cover string literals, when <option>-X-OverloadedStrings</option> is specified.
+Haskell's defaulting mechanism is extended to cover string literals, when <option>-XOverloadedStrings</option> is specified.
Specifically:
<itemizedlist>
<listitem><para>
guide when it has stabilised.
</para>
<para>
-Type families are enabled by the flag <option>-X=TypeFamilies</option>.
+Type families are enabled by the flag <option>-XTypeFamilies</option>.
</para>
<para> Template Haskell has the following new syntactic
constructions. You need to use the flag
- <option>-X=TemplateHaskell</option> or <option>-X=TH</option>
- <indexterm><primary><option>-X=TemplateHaskell</option></primary>
+ <option>-XTemplateHaskell</option>
+ <indexterm><primary><option>-XTemplateHaskell</option></primary>
</indexterm>to switch these syntactic extensions on
- (<option>-X=TemplateHaskell</option> is no longer implied by
+ (<option>-XTemplateHaskell</option> is no longer implied by
<option>-fglasgow-exts</option>).</para>
<itemizedlist>
<para>Now run the compiler (here we are a Cygwin prompt on Windows):
</para>
<programlisting>
-$ ghc --make -X=TemplateHaskell main.hs -o main.exe
+$ ghc --make -XTemplateHaskell main.hs -o main.exe
</programlisting>
<para>Run "main.exe" and here is your output:</para>
</itemizedlist>
and the arrows web page at
<ulink url="http://www.haskell.org/arrows/"><literal>http://www.haskell.org/arrows/</literal></ulink>.
-With the <option>-X=Arrows</option> flag, GHC supports the arrow
+With the <option>-XArrows</option> flag, GHC supports the arrow
notation described in the second of these papers.
What follows is a brief introduction to the notation;
it won't make much sense unless you've read Hughes's paper.
than the material below.
</para>
<para>
-Bang patterns are enabled by the flag <option>-X=BangPatterns</option>.
+Bang patterns are enabled by the flag <option>-XBangPatterns</option>.
</para>
<sect2 id="bang-patterns-informal">
<itemizedlist>
<listitem>
<para>Use the flags <option>-fglasgow-exts</option> (to enable the extra syntax),
- <option>-X=Generics</option> (to generate extra per-data-type code),
+ <option>-XGenerics</option> (to generate extra per-data-type code),
and <option>-package lang</option> (to make the <literal>Generics</literal> library
available. </para>
</listitem>
<sect2>
<title>Switching off the dreaded Monomorphism Restriction</title>
- <indexterm><primary><option>-X=NoMonomorphismRestriction</option></primary></indexterm>
+ <indexterm><primary><option>-XNoMonomorphismRestriction</option></primary></indexterm>
<para>Haskell's monomorphism restriction (see
<ulink url="http://haskell.org/onlinereport/decls.html#sect4.5.5">Section
4.5.5</ulink>
of the Haskell Report)
can be completely switched off by
-<option>-X=NoMonomorphismRestriction</option>.
+<option>-XNoMonomorphismRestriction</option>.
</para>
</sect2>
<sect2>
<title>Monomorphic pattern bindings</title>
- <indexterm><primary><option>-X=NoMonoPatBinds</option></primary></indexterm>
- <indexterm><primary><option>-X=MonoPatBinds</option></primary></indexterm>
+ <indexterm><primary><option>-XNoMonoPatBinds</option></primary></indexterm>
+ <indexterm><primary><option>-XMonoPatBinds</option></primary></indexterm>
<para> As an experimental change, we are exploring the possibility of
making pattern bindings monomorphic; that is, not generalised at all.
[x] = e -- A pattern binding
</programlisting>
Experimentally, GHC now makes pattern bindings monomorphic <emphasis>by
-default</emphasis>. Use <option>-X=MonoPatBinds</option> to recover the
+default</emphasis>. Use <option>-XMonoPatBinds</option> to recover the
standard behaviour.
</para>
</sect2>
projects / ghc-hetmet.git / blobdiff