Three improvements to Template Haskell (fixes #3467)
[ghc-hetmet.git] / docs / users_guide / glasgow_exts.xml
index c0feb5b..fb21918 100644 (file)
@@ -840,6 +840,19 @@ y)</literal> will not be coalesced.
 
 </sect2>
 
+    <!-- ===================== n+k patterns ===================  -->
+
+<sect2 id="n-k-patterns">
+<title>n+k patterns</title>
+<indexterm><primary><option>-XNoNPlusKPatterns</option></primary></indexterm>
+
+<para>
+<literal>n+k</literal> pattern support is enabled by default. To disable
+it, you can use the <option>-XNoNPlusKPatterns</option> flag.
+</para>
+
+</sect2>
+
     <!-- ===================== Recursive do-notation ===================  -->
 
 <sect2 id="mdo-notation">
@@ -1323,7 +1336,6 @@ module Foo where
   data T = MkT { x :: Int }
   
   ok1 (MkS { x = n }) = n+1   -- Unambiguous
-
   ok2 n = MkT { x = n+1 }     -- Unambiguous
 
   bad1 k = k { x = 3 }  -- Ambiguous
@@ -1348,6 +1360,37 @@ if there are other variables in scope with the same name.
 This reduces the clutter of qualified names when you import two
 records from different modules that use the same field name.
 </para>
+<para>
+Some details:
+<itemizedlist>
+<listitem><para>
+Field disambiguation can be combined with punning (see <xref linkend="record-puns"/>). For exampe:
+<programlisting>
+module Foo where
+  import M
+  x=True
+  ok3 (MkS { x }) = x+1   -- Uses both disambiguation and punning
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+With <option>-XDisambiguateRecordFields</option> you can use <emphasis>unqualifed</emphasis>
+field names even if the correponding selector is only in scope <emphasis>qualified</emphasis>
+For example, assuming the same module <literal>M</literal> as in our earlier example, this is legal:
+<programlisting>
+module Foo where
+  import qualified M    -- Note qualified
+
+  ok4 (M.MkS { x = n }) = n+1   -- Unambiguous
+</programlisting>
+Since the constructore <literal>MkS</literal> is only in scope qualified, you must
+name it <literal>M.MkS</literal>, but the field <literal>x</literal> does not need
+to be qualified even though <literal>M.x</literal> is in scope but <literal>x</literal>
+is not.  (In effect, it is qualified by the constructor.)
+</para></listitem>
+</itemizedlist>
+</para>
+
 </sect2>
 
     <!-- ===================== Record puns ===================  -->
@@ -1384,16 +1427,9 @@ a</literal> for the same name <literal>a</literal>.
 </para>
 
 <para>
-Note that puns and other patterns can be mixed in the same record:
-<programlisting>
-data C = C {a :: Int, b :: Int}
-f (C {a, b = 4}) = a
-</programlisting>
-and that puns can be used wherever record patterns occur (e.g. in
-<literal>let</literal> bindings or at the top-level).  
-</para>
-
-<para>
+Note that:
+<itemizedlist>
+<listitem><para>
 Record punning can also be used in an expression, writing, for example,
 <programlisting>
 let a = 1 in C {a}
@@ -1402,12 +1438,41 @@ instead of
 <programlisting>
 let a = 1 in C {a = a}
 </programlisting>
-
-Note that this expansion is purely syntactic, so the record pun
+The expansion is purely syntactic, so the expanded right-hand side
 expression refers to the nearest enclosing variable that is spelled the
 same as the field name.
+</para></listitem>
+
+<listitem><para>
+Puns and other patterns can be mixed in the same record:
+<programlisting>
+data C = C {a :: Int, b :: Int}
+f (C {a, b = 4}) = a
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+Puns can be used wherever record patterns occur (e.g. in
+<literal>let</literal> bindings or at the top-level).  
+</para></listitem>
+
+<listitem><para>
+A pun on a qualified field name is expanded by stripping off the module qualifier.
+For example:
+<programlisting>
+f (C {M.a}) = a
+</programlisting>
+means
+<programlisting>
+f (M.C {M.a = a}) = a
+</programlisting>
+(This is useful if the field selector <literal>a</literal> for constructor <literal>M.C</literal>
+is only in scope in qualified form.)
+</para></listitem>
+</itemizedlist>
 </para>
 
+
 </sect2>
 
     <!-- ===================== Record wildcards ===================  -->
@@ -1418,6 +1483,7 @@ same as the field name.
 
 <para>
 Record wildcards are enabled by the flag <literal>-XRecordWildCards</literal>.
+This flag implies <literal>-XDisambiguateRecordFields</literal>.
 </para>
 
 <para>
@@ -1430,7 +1496,7 @@ f (C {a = 1, b = b, c = c, d = d}) = b + c + d
 </para>
 
 <para>
-Record wildcard syntax permits a (<literal>..</literal>) in a record
+Record wildcard syntax permits a "<literal>..</literal>" in a record
 pattern, where each elided field <literal>f</literal> is replaced by the
 pattern <literal>f = f</literal>.  For example, the above pattern can be
 written as
@@ -1440,7 +1506,10 @@ f (C {a = 1, ..}) = b + c + d
 </para>
 
 <para>
-Note that wildcards can be mixed with other patterns, including puns
+More details:
+<itemizedlist>
+<listitem><para>
+Wildcards can be mixed with other patterns, including puns
 (<xref linkend="record-puns"/>); for example, in a pattern <literal>C {a
 = 1, b, ..})</literal>.  Additionally, record wildcards can be used
 wherever record patterns occur, including in <literal>let</literal>
@@ -1450,24 +1519,38 @@ C {a = 1, ..} = e
 </programlisting>
 defines <literal>b</literal>, <literal>c</literal>, and
 <literal>d</literal>.
-</para>
+</para></listitem>
 
-<para>
+<listitem><para>
 Record wildcards can also be used in expressions, writing, for example,
-
 <programlisting>
 let {a = 1; b = 2; c = 3; d = 4} in C {..}
 </programlisting>
-
 in place of
-
 <programlisting>
 let {a = 1; b = 2; c = 3; d = 4} in C {a=a, b=b, c=c, d=d}
 </programlisting>
-
-Note that this expansion is purely syntactic, so the record wildcard
+The expansion is purely syntactic, so the record wildcard
 expression refers to the nearest enclosing variables that are spelled
 the same as the omitted field names.
+</para></listitem>
+
+<listitem><para>
+The "<literal>..</literal>" expands to the missing 
+<emphasis>in-scope</emphasis> record fields, where "in scope"
+includes both unqualified and qualified-only.  
+Any fields that are not in scope are not filled in.  For example
+<programlisting>
+module M where
+  data R = R { a,b,c :: Int }
+module X where
+  import qualified M( R(a,b) )
+  f a b = R { .. }
+</programlisting>
+The <literal>{..}</literal> expands to <literal>{M.a=a,M.b=b}</literal>,
+omitting <literal>c</literal> since it is not in scope at all.
+</para></listitem>
+</itemizedlist>
 </para>
 
 </sect2>
@@ -3074,7 +3157,8 @@ All the extensions are enabled by the <option>-fglasgow-exts</option> flag.
 <sect3>
 <title>Multi-parameter type classes</title>
 <para>
-Multi-parameter type classes are permitted. For example:
+Multi-parameter type classes are permitted, with flag <option>-XMultiParamTypeClasses</option>. 
+For example:
 
 
 <programlisting>
@@ -3086,13 +3170,17 @@ Multi-parameter type classes are permitted. For example:
 </para>
 </sect3>
 
-<sect3>
+<sect3 id="superclass-rules">
 <title>The superclasses of a class declaration</title>
 
 <para>
-There are no restrictions on the context in a class declaration
-(which introduces superclasses), except that the class hierarchy must
-be acyclic.  So these class declarations are OK:
+In Haskell 98 the context of a class declaration (which introduces superclasses)
+must be simple; that is, each predicate must consist of a class applied to 
+type variables.  The flag <option>-XFlexibleContexts</option> 
+(<xref linkend="flexible-contexts"/>)
+lifts this restriction,
+so that the only restriction on the context in a class declaration is 
+that the class hierarchy must be acyclic.  So these class declarations are OK:
 
 
 <programlisting>
@@ -4640,7 +4728,11 @@ these type signatures are perfectly OK
   g :: Eq [a] => ...
   g :: Ord (T a ()) => ...
 </programlisting>
+The flag <option>-XFlexibleContexts</option> also lifts the corresponding
+restriction on class declarations (<xref linkend="superclass-rules"/>) and instance declarations
+(<xref linkend="instance-rules"/>).
 </para>
+
 <para>
 GHC imposes the following restrictions on the constraints in a type signature.
 Consider the type:
@@ -5973,12 +6065,11 @@ Wiki page</ulink>.
                    have type <literal>Q Exp</literal></para></listitem>
                    <listitem><para> an type; the spliced expression must
                    have type <literal>Q Typ</literal></para></listitem>
-                   <listitem><para> a list of top-level declarations; the spliced expression must have type <literal>Q [Dec]</literal></para></listitem>
+                   <listitem><para> a list of top-level declarations; the spliced expression 
+                    must have type <literal>Q [Dec]</literal></para></listitem>
                    </itemizedlist>
-               </para>
            Inside a splice you can can only call functions defined in imported modules,
-       not functions defined elsewhere in the same module.</listitem>
-
+       not functions defined elsewhere in the same module.</para></listitem>
 
              <listitem><para>
                  A expression quotation is written in Oxford brackets, thus:
@@ -5995,7 +6086,7 @@ Wiki page</ulink>.
                  A quasi-quotation can appear in either a pattern context or an
                  expression context and is also written in Oxford brackets:
                  <itemizedlist>
-                   <listitem><para> <literal>[:<replaceable>varid</replaceable>| ... |]</literal>,
+                   <listitem><para> <literal>[$<replaceable>varid</replaceable>| ... |]</literal>,
                         where the "..." is an arbitrary string; a full description of the
                        quasi-quotation facility is given in <xref linkend="th-quasiquotation"/>.</para></listitem>
                  </itemizedlist></para></listitem>
@@ -6016,6 +6107,25 @@ Wiki page</ulink>.
                 </para>
                </listitem>
 
+             <listitem><para> You may omit the <literal>$(...)</literal> in a top-level declaration splice. 
+              Simply writing an expression (rather than a declaration) implies a splice.  For example, you can write
+<programlisting>
+module Foo where
+import Bar
+
+f x = x
+
+$(deriveStuff 'f)   -- Uses the $(...) notation
+
+g y = y+1
+
+deriveStuff 'g      -- Omits the $(...)
+
+h z = z-1
+</programlisting>
+            This abbreviation makes top-level declaration slices quieter and less intimidating.
+           </para></listitem>
+
                  
        </itemizedlist>
 (Compared to the original paper, there are many differences of detail.
@@ -7180,24 +7290,11 @@ Assertion failures can be caught, see the documentation for the
     <sect2 id="include-pragma">
       <title>INCLUDE pragma</title>
 
-      <para>The <literal>INCLUDE</literal> pragma is for specifying the names
-       of C header files that should be <literal>#include</literal>'d into
-       the C source code generated by the compiler for the current module (if
-       compiling via C).  For example:</para>
-
-<programlisting>
-{-# INCLUDE "foo.h" #-}
-{-# INCLUDE &lt;stdio.h&gt; #-}</programlisting>
-
-        <para><literal>INCLUDE</literal> is a file-header pragma (see <xref linkend="pragmas"/>).</para>
-
-      <para>An <literal>INCLUDE</literal> pragma is  the preferred alternative
-       to the <option>-#include</option> option (<xref
-         linkend="options-C-compiler" />), because the
-       <literal>INCLUDE</literal> pragma is understood by other
-       compilers.  Yet another alternative is to add the include file to each
-       <literal>foreign import</literal> declaration in your code, but we
-       don't recommend using this approach with GHC.</para>
+      <para>The <literal>INCLUDE</literal> used to be necessary for
+        specifying header files to be included when using the FFI and
+        compiling via C.  It is no longer required for GHC, but is
+        accepted (and ignored) for compatibility with other
+        compilers.</para>
     </sect2>
 
     <sect2 id="warning-deprecated-pragma">