<indexterm><primary>extensions</primary><secondary>options controlling</secondary>
</indexterm>
- <para>The language option flag control what variation of the language are
+ <para>The language option flags control what variation of the language are
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>",
- 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>-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>Language options can be controlled in two ways:
+ <itemizedlist>
+ <listitem><para>Every language option can switched on by a command-line flag "<option>-X...</option>"
+ (e.g. <option>-XTemplateHaskell</option>), and switched off by the flag "<option>-XNo...</option>";
+ (e.g. <option>-XNoTemplateHaskell</option>).</para></listitem>
+ <listitem><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>
+ </listitem>
+ </itemizedlist></para>
<para>The flag <option>-fglasgow-exts</option>
<indexterm><primary><option>-fglasgow-exts</option></primary></indexterm>
the syntax by eliminating odd cases
like <literal>Prelude..</literal>. For example,
when <literal>NewQualifiedOperators</literal> is on, it is possible to
- write the enerated sequence <literal>[Monday..]</literal>
+ write the enumerated sequence <literal>[Monday..]</literal>
without spaces, whereas in Haskell 98 this would be a
reference to the operator ‘<literal>.</literal>‘
from module <literal>Monday</literal>.</para>
newtype instance T Char = TC Bool
</programlisting>
</para></listitem>
- <listitem><para> A <data instance> can use GADT syntax for the data constructors,
+ <listitem><para> A <literal>data instance</literal> can use GADT syntax for the data constructors,
and indeed can define a GADT. For example:
<programlisting>
data family G a b
<indexterm><primary>Bang patterns</primary></indexterm>
</title>
<para>GHC supports an extension of pattern matching called <emphasis>bang
-patterns</emphasis>. Bang patterns are under consideration for Haskell Prime.
+patterns</emphasis>, written <literal>!<replaceable>pat</replaceable></literal>.
+Bang patterns are under consideration for Haskell Prime.
The <ulink
url="http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns">Haskell
prime feature description</ulink> contains more discussion and examples
than the material below.
</para>
<para>
+The key change is the addition of a new rule to the
+<ulink url="http://haskell.org/onlinereport/exps.html#sect3.17.2">semantics of pattern matching in the Haskell 98 report</ulink>.
+Add new bullet 10, saying: Matching the pattern <literal>!</literal><replaceable>pat</replaceable>
+against a value <replaceable>v</replaceable> behaves as follows:
+<itemizedlist>
+<listitem><para>if <replaceable>v</replaceable> is bottom, the match diverges</para></listitem>
+<listitem><para>otherwise, <replaceable>pat</replaceable> is matched against <replaceable>v</replaceable> </para></listitem>
+</itemizedlist>
+</para>
+<para>
Bang patterns are enabled by the flag <option>-XBangPatterns</option>.
</para>
f3 !(x,y) = [x,y]
f4 (x,y) = [x,y]
</programlisting>
-Here, <literal>f3</literal> and <literal>f4</literal> are identical; putting a bang before a pattern that
+Here, <literal>f3</literal> and <literal>f4</literal> are identical;
+putting a bang before a pattern that
forces evaluation anyway does nothing.
-</para><para>
+</para>
+<para>
+There is one (apparent) exception to this general rule that a bang only
+makes a difference when it precedes a variable or wild-card: a bang at the
+top level of a <literal>let</literal> or <literal>where</literal>
+binding makes the binding strict, regardless of the pattern. For example:
+<programlisting>
+let ![x,y] = e in b
+</programlisting>
+is a strict binding: operationally, it evaluates <literal>e</literal>, matches
+it against the pattern <literal>[x,y]</literal>, and then evaluates <literal>b</literal>.
+(We say "apparent" exception because the Right Way to think of it is that the bang
+at the top of a binding is not part of the <emphasis>pattern</emphasis>; rather it
+is part of the syntax of the <emphasis>binding</emphasis>.)
+Nested bangs in a pattern binding behave uniformly with all other forms of
+pattern matching. For example
+<programlisting>
+let (!x,[y]) = e in b
+</programlisting>
+is equivalent to this:
+<programlisting>
+let { t = case e of (x,[y]) -> x `seq` (x,y)
+ x = fst t
+ y = snd t }
+in b
+</programlisting>
+The binding is lazy, but when either <literal>x</literal> or <literal>y</literal> is
+evaluated by <literal>b</literal> the entire pattern is matched, including forcing the
+evaluation of <literal>x</literal>.
+</para>
+<para>
Bang patterns work in <literal>case</literal> expressions too, of course:
<programlisting>
g5 x = let y = f x in body
The functions <literal>g5</literal> and <literal>g6</literal> mean exactly the same thing.
But <literal>g7</literal> evaluates <literal>(f x)</literal>, binds <literal>y</literal> to the
result, and then evaluates <literal>body</literal>.
-</para><para>
-Bang patterns work in <literal>let</literal> and <literal>where</literal>
-definitions too. For example:
-<programlisting>
-let ![x,y] = e in b
-</programlisting>
-is a strict pattern: operationally, it evaluates <literal>e</literal>, matches
-it against the pattern <literal>[x,y]</literal>, and then evaluates <literal>b</literal>
-The "<literal>!</literal>" should not be regarded as part of the pattern; after all,
-in a function argument <literal>![x,y]</literal> means the
-same as <literal>[x,y]</literal>. Rather, the "<literal>!</literal>"
-is part of the syntax of <literal>let</literal> bindings.
</para>
</sect2>
<replaceable>word</replaceable>. The various values for
<replaceable>word</replaceable> that GHC understands are described
in the following sections; any pragma encountered with an
- unrecognised <replaceable>word</replaceable> is (silently)
+ unrecognised <replaceable>word</replaceable> is
ignored. The layout rule applies in pragmas, so the closing <literal>#-}</literal>
should start in a column to the right of the opening <literal>{-#</literal>. </para>
- <para>Certain pragmas are <emphasis>file-header pragmas</emphasis>. A file-header
- pragma must precede the <literal>module</literal> keyword in the file.
+ <para>Certain pragmas are <emphasis>file-header pragmas</emphasis>:
+ <itemizedlist>
+ <listitem><para>
+ A file-header
+ pragma must precede the <literal>module</literal> keyword in the file.
+ </para></listitem>
+ <listitem><para>
There can be as many file-header pragmas as you please, and they can be
- preceded or followed by comments.</para>
+ preceded or followed by comments.
+ </para></listitem>
+ <listitem><para>
+ File-header pragmas are read once only, before
+ pre-processing the file (e.g. with cpp).
+ </para></listitem>
+ <listitem><para>
+ The file-header pragmas are: <literal>{-# LANGUAGE #-}</literal>,
+ <literal>{-# OPTIONS_GHC #-}</literal>, and
+ <literal>{-# INCLUDE #-}</literal>.
+ </para></listitem>
+ </itemizedlist>
+ </para>
<sect2 id="language-pragma">
<title>LANGUAGE pragma</title>
<title>Special built-in functions</title>
<para>GHC has a few built-in functions with special behaviour. These
are now described in the module <ulink
-url="../libraries/base/GHC-Prim.html"><literal>GHC.Prim</literal></ulink>
+url="../libraries/ghc-prim/GHC-Prim.html"><literal>GHC.Prim</literal></ulink>
in the library documentation.</para>
</sect1>
projects / ghc-hetmet.git / blobdiff