<varlistentry>
<term>
- <option>-fno-monomorphism-restriction</option>:
- <indexterm><primary><option>-fno-monomorphism-restriction</option></primary></indexterm>
+ <option>-fno-monomorphism-restriction</option>,<option>-fno-monomorphism-restriction</option>:
+ </term>
+ <listitem>
+ <para> These two flags control how generalisation is done in
+ See <xref linkend="monomorphism"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fextended-default-rules</option>:
+ <indexterm><primary><option>-fextended-default-rules</option></primary></indexterm>
</term>
<listitem>
- <para> Switch off the Haskell 98 monomorphism restriction.
+ <para> Use GHCi's extended default rules in a regular module (<xref linkend="extended-default-rules"/>).
Independent of the <option>-fglasgow-exts</option>
flag. </para>
</listitem>
<indexterm><primary><option>-fallow-incoherent-instances</option></primary></indexterm>
</term>
<term>
- <option>-fcontext-stack</option>
+ <option>-fcontext-stack=N</option>
<indexterm><primary><option>-fcontext-stack</option></primary></indexterm>
</term>
<listitem>
Nothing -> fail
Just val2 -> val1 + val2
where
- fail = val1 + val2
+ fail = var1 + var2
</programlisting>
<para>
op = ... -- Default
</programlisting>
</para>
+<para>You can find lots of background material about the reason for these
+restrictions in the paper <ulink
+url="http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/">
+Understanding functional dependencies via Constraint Handling Rules</ulink>.
+</para>
</sect3>
<sect3 id="undecidable-instances">
types in both an instance context and instance head. Termination is ensured by having a
fixed-depth recursion stack. If you exceed the stack depth you get a
sort of backtrace, and the opportunity to increase the stack depth
-with <option>-fcontext-stack</option><emphasis>N</emphasis>.
+with <option>-fcontext-stack=</option><emphasis>N</emphasis>.
</para>
</sect3>
</primary></indexterm>
and <option>-fallow-incoherent-instances</option>
<indexterm><primary>-fallow-incoherent-instances
-</primary></indexterm>, as this section discusses.</para>
+</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>
When GHC tries to resolve, say, the constraint <literal>C Int Bool</literal>,
it tries to match every instance declaration against the
to pick out the least value in a list:
<programlisting>
least :: (?cmp :: a -> a -> Bool) => [a] -> a
- least xs = fst (sort xs)
+ least xs = head (sort xs)
</programlisting>
Without lifting a finger, the <literal>?cmp</literal> parameter is
propagated to become a parameter of <literal>least</literal> as well. With explicit
</sect3>
</sect2>
+ <!-- ======================= COMMENTED OUT ========================
+
+ We intend to remove linear implicit parameters, so I'm at least removing
+ them from the 6.6 user manual
+
<sect2 id="linear-implicit-parameters">
<title>Linear implicit parameters</title>
<para>
<para>
Linear implicit parameters are just like ordinary implicit parameters,
-except that they are "linear" -- that is, they cannot be copied, and
+except that they are "linear"; that is, they cannot be copied, and
must be explicitly "split" instead. Linear implicit parameters are
written '<literal>%x</literal>' instead of '<literal>?x</literal>'.
(The '/' in the '%' suggests the split!)
</sect2>
+================ END OF Linear Implicit Parameters commented out -->
+
<sect2 id="sec-kinding">
<title>Explicitly-kinded quantification</title>
</programlisting>
</sect2>
+
+<sect2>
+<title>Using Template Haskell with Profiling</title>
+<indexterm><primary>profiling</primary><secondary>with Template Haskell</secondary></indexterm>
+<para>Template Haskell relies on GHC's built-in bytecode compiler and
+interpreter to run the splice expressions. The bytecode interpreter
+runs the compiled expression on top of the same runtime on which GHC
+itself is running; this means that the compiled code referred to by
+the interpreted expression must be compatible with this runtime, and
+in particular this means that object code that is compiled for
+profiling <emphasis>cannot</emphasis> be loaded and used by a splice
+expression, because profiled object code is only compatible with the
+profiling version of the runtime.</para>
+
+<para>This causes difficulties if you have a multi-module program
+containing Template Haskell code and you need to compile it for
+profiling, because GHC cannot load the profiled object code and use it
+when executing the splices. Fortunately GHC provides a workaround.
+The basic idea is to compile the program twice:</para>
+
+<orderedlist>
+<listitem>
+ <para>Compile the program or library first the normal way, without
+ <option>-prof</option><indexterm><primary><option>-prof</option></primary></indexterm>.</para>
+</listitem>
+<listitem>
+ <para>Then compile it again with <option>-prof</option>, and
+ additionally use <option>-osuf
+ p_o</option><indexterm><primary><option>-osuf</option></primary></indexterm>
+ to name the object files differentliy (you can choose any suffix
+ that isn't the normal object suffix here). GHC will automatically
+ load the object files built in the first step when executing splice
+ expressions. If you omit the <option>-osuf</option> flag when
+ building with <option>-prof</option> and Template Haskell is used,
+ GHC will emit an error message. </para>
+</listitem>
+</orderedlist>
+</sect2>
+
</sect1>
<!-- ===================== Arrow notation =================== -->
</sect1>
+<!-- ==================== BANG PATTERNS ================= -->
+
+<sect1 id="sec-bang-patterns">
+<title>Bang patterns
+<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.
+The <ulink
+url="http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns">the
+Haskell prime feature description</ulink> contains more discussion and examples
+than the material below.
+</para>
+<para>
+Bang patterns are enabled by the flag <option>-fbang-patterns</option>.
+</para>
+
+<sect2 id="sec-bang-patterns-informal">
+<title>Informal description of bang patterns
+</title>
+<para>
+The main idea is to add a single new production to the syntax of patterns:
+<programlisting>
+ pat ::= !pat
+</programlisting>
+Matching an expression <literal>e</literal> against a pattern <literal>!p</literal> is done by first
+evaluating <literal>e</literal> (to WHNF) and then matching the result against <literal>p</literal>.
+Example:
+<programlisting>
+f1 !x = True
+</programlisting>
+This definition makes <literal>f1</literal> is strict in <literal>x</literal>,
+whereas without the bang it would be lazy.
+Bang patterns can be nested of course:
+<programlisting>
+f2 (!x, y) = [x,y]
+</programlisting>
+Here, <literal>f2</literal> is strict in <literal>x</literal> but not in
+<literal>y</literal>.
+A bang only really has an effect if it precedes a variable or wild-card pattern:
+<programlisting>
+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
+forces evaluation anyway does nothing.
+</para><para>
+Bang patterns work in <literal>case</literal> expressions too, of course:
+<programlisting>
+g5 x = let y = f x in body
+g6 x = case f x of { y -> body }
+g7 x = case f x of { !y -> body }
+</programlisting>
+The functions <literal>g5</literal> and <literal>g6</literal> mean exactly the same thing.
+But <literal>g7</literal> evalutes <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>
+
+
+<sect2 id="sec-bang-patterns-sem">
+<title>Syntax and semantics
+</title>
+<para>
+
+We add a single new production to the syntax of patterns:
+<programlisting>
+ pat ::= !pat
+</programlisting>
+There is one problem with syntactic ambiguity. Consider:
+<programlisting>
+f !x = 3
+</programlisting>
+Is this a definition of the infix function "<literal>(!)</literal>",
+or of the "<literal>f</literal>" with a bang pattern? GHC resolves this
+ambiguity inf favour of the latter. If you want to define
+<literal>(!)</literal> with bang-patterns enabled, you have to do so using
+prefix notation:
+<programlisting>
+(!) f x = 3
+</programlisting>
+The semantics of Haskell pattern matching is described in <ulink
+url="http://haskell.org/onlinereport/exps.html#sect3.17.2">
+Section 3.17.2</ulink> of the Haskell Report. To this description add
+one extra item 10, saying:
+<itemizedlist><listitem><para>Matching
+the pattern <literal>!pat</literal> against a value <literal>v</literal> behaves as follows:
+<itemizedlist><listitem><para>if <literal>v</literal> is bottom, the match diverges</para></listitem>
+ <listitem><para>otherwise, <literal>pat</literal> is matched against
+ <literal>v</literal></para></listitem>
+</itemizedlist>
+</para></listitem></itemizedlist>
+Similarly, in Figure 4 of <ulink url="http://haskell.org/onlinereport/exps.html#sect3.17.3">
+Section 3.17.3</ulink>, add a new case (t):
+<programlisting>
+case v of { !pat -> e; _ -> e' }
+ = v `seq` case v of { pat -> e; _ -> e' }
+</programlisting>
+</para><para>
+That leaves let expressions, whose translation is given in
+<ulink url="http://haskell.org/onlinereport/exps.html#sect3.12">Section
+3.12</ulink>
+of the Haskell Report.
+In the translation box, first apply
+the following transformation: for each pattern <literal>pi</literal> that is of
+form <literal>!qi = ei</literal>, transform it to <literal>(xi,!qi) = ((),ei)</literal>, and and replace <literal>e0</literal>
+by <literal>(xi `seq` e0)</literal>. Then, when none of the left-hand-side patterns
+have a bang at the top, apply the rules in the existing box.
+</para>
+<para>The effect of the let rule is to force complete matching of the pattern
+<literal>qi</literal> before evaluation of the body is begun. The bang is
+retained in the translated form in case <literal>qi</literal> is a variable,
+thus:
+<programlisting>
+ let !y = f x in b
+</programlisting>
+
+</para>
+<para>
+The let-binding can be recursive. However, it is much more common for
+the let-binding to be non-recursive, in which case the following law holds:
+<literal>(let !p = rhs in body)</literal>
+ is equivalent to
+<literal>(case rhs of !p -> body)</literal>
+</para>
+<para>
+A pattern with a bang at the outermost level is not allowed at the top level of
+a module.
+</para>
+</sect2>
+</sect1>
+
<!-- ==================== ASSERTIONS ================= -->
<sect1 id="sec-assertions">
(in a pragma). GHC applies these rewrite rules wherever it can, provided (a)
the <option>-O</option> flag (<xref linkend="options-optimise"/>) is on,
and (b) the <option>-frules-off</option> flag
-(<xref linkend="options-f"/>) is not specified.
+(<xref linkend="options-f"/>) is not specified, and (c) the
+<option>-fglasgow-exts</option> (<xref linkend="options-language"/>)
+flag is active.
</para>
<para>
</sect1>
+<sect1 id="special-ids">
+<title>Special built-in functions</title>
+<para>GHC has a few built-in funcions with special behaviour,
+described in this section. All are exported by
+<literal>GHC.Exts</literal>.</para>
+
+<sect2> <title>The <literal>inline</literal> function </title>
+<para>
+The <literal>inline</literal> function is somewhat experimental.
+<programlisting>
+ inline :: a -> a
+</programlisting>
+The call <literal>(inline f)</literal> arranges that <literal>f</literal>
+is inlined, regardless of its size. More precisely, the call
+<literal>(inline f)</literal> rewrites to the right-hand side of <literal>f</literal>'s
+definition.
+This allows the programmer to control inlining from
+a particular <emphasis>call site</emphasis>
+rather than the <emphasis>definition site</emphasis> of the function
+(c.f. <literal>INLINE</literal> pragmas <xref linkend="inline-noinline-pragma"/>).
+</para>
+<para>
+This inlining occurs regardless of the argument to the call
+or the size of <literal>f</literal>'s definition; it is unconditional.
+The main caveat is that <literal>f</literal>'s definition must be
+visible to the compiler. That is, <literal>f</literal> must be
+let-bound in the current scope.
+If no inlining takes place, the <literal>inline</literal> function
+expands to the identity function in Phase zero; so its use imposes
+no overhead.</para>
+
+<para> If the function is defined in another
+module, GHC only exposes its inlining in the interface file if the
+function is sufficiently small that it <emphasis>might</emphasis> be
+inlined by the automatic mechanism. There is currently no way to tell
+GHC to expose arbitrarily-large functions in the interface file. (This
+shortcoming is something that could be fixed, with some kind of pragma.)
+</para>
+</sect2>
+
+<sect2> <title>The <literal>lazy</literal> function </title>
+<para>
+The <literal>lazy</literal> function restrains strictness analysis a little:
+<programlisting>
+ lazy :: a -> a
+</programlisting>
+The call <literal>(lazy e)</literal> means the same as <literal>e</literal>,
+but <literal>lazy</literal> has a magical property so far as strictness
+analysis is concerned: it is lazy in its first argument,
+even though its semantics is strict. After strictness analysis has run,
+calls to <literal>lazy</literal> are inlined to be the identity function.
+</para>
+<para>
+This behaviour is occasionally useful when controlling evaluation order.
+Notably, <literal>lazy</literal> is used in the library definition of
+<literal>Control.Parallel.par</literal>:
+<programlisting>
+ par :: a -> b -> b
+ par x y = case (par# x) of { _ -> lazy y }
+</programlisting>
+If <literal>lazy</literal> were not lazy, <literal>par</literal> would
+look strict in <literal>y</literal> which would defeat the whole
+purpose of <literal>par</literal>.
+</para>
+</sect2>
+
+<sect2> <title>The <literal>unsafeCoerce#</literal> function </title>
+<para>
+The function <literal>unsafeCoerce#</literal> allows you to side-step the
+typechecker entirely. It has type
+<programlisting>
+ unsafeCoerce# :: a -> b
+</programlisting>
+That is, it allows you to coerce any type into any other type. If you use this
+function, you had better get it right, otherwise segmentation faults await.
+It is generally used when you want to write a program that you know is
+well-typed, but where Haskell's type system is not expressive enough to prove
+that it is well typed.
+</para>
+</sect2>
+</sect1>
+
+
<sect1 id="generic-classes">
<title>Generic classes</title>
</sect2>
</sect1>
+<sect1 id="monomorphism">
+<title>Control over monomorphism</title>
+
+<para>GHC supports two flags that control the way in which generalisation is
+carried out at let and where bindings.
+</para>
+
+<sect2>
+<title>Switching off the dreaded Monomorphism Restriction</title>
+ <indexterm><primary><option>-fno-monomorphism-restriction</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>-fno-monomorphism-restriction</option>.
+</para>
+</sect2>
+
+<sect2>
+<title>Monomorphic patteern bindings</title>
+ <indexterm><primary><option>-fno-mono-pat-binds</option></primary></indexterm>
+ <indexterm><primary><option>-fmono-pat-binds</option></primary></indexterm>
+
+ <para> As an experimental change, we are exploring the possibility of
+ making pattern bindings monomorphic; that is, not generalised at all.
+ A pattern binding is a binding whose LHS has no function arguments,
+ and is not a simple variable. For example:
+<programlisting>
+ f x = x -- Not a pattern binding
+ f = \x -> x -- Not a pattern binding
+ f :: Int -> Int = \x -> x -- Not a pattern binding
+
+ (g,h) = e -- A pattern binding
+ (f) = e -- A pattern binding
+ [x] = e -- A pattern binding
+</programlisting>
+Experimentally, GHC now makes pattern bindings monomorphic <emphasis>by
+default</emphasis>. Use <option>-fno-mono-pat-binds</option> to recover the
+standard behaviour.
+</para>
+</sect2>
+</sect1>
+
<!-- Emacs stuff: