doc.diff

diff -urd 7.8.2-original/glasgow_exts.xml original/glasgow_exts.xml
--- 7.8.2-original/glasgow_exts.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/glasgow_exts.xml	2016-04-09 21:36:11.394998369 +0900
@@ -3,7 +3,7 @@
 <indexterm><primary>language, GHC</primary></indexterm>
 <indexterm><primary>extensions, GHC</primary></indexterm>
 As with all known Haskell systems, GHC implements some extensions to
-the language.  They can all be enabled or disabled by commandline flags
+the language.  They can all be enabled or disabled by command line flags
 or language pragmas. By default GHC understands the most recent Haskell
 version it supports, plus a handful of extensions.
 </para>
@@ -456,10 +456,10 @@
       </para>
 
       <para>
-      This can make a difference when the positive and negative range of 
-      a numeric data type don't match up.  For example, 
+      This can make a difference when the positive and negative range of
+      a numeric data type don't match up.  For example,
       in 8-bit arithmetic -128 is representable, but +128 is not.
-      So <literal>negate (fromInteger 128)</literal> will elicit an 
+      So <literal>negate (fromInteger 128)</literal> will elicit an
       unexpected integer-literal-overflow message.
       </para>
    </sect2>
@@ -480,6 +480,26 @@
       </para>
    </sect2>
 
+    <sect2 id="binary-literals">
+      <title>Binary integer literals</title>
+      <para>
+          Haskell 2010 and Haskell 98 allows for integer literals to
+          be given in decimal, octal (prefixed by
+          <literal>0o</literal> or <literal>0O</literal>), or
+          hexadecimal notation (prefixed by <literal>0x</literal> or
+          <literal>0X</literal>).
+      </para>
+
+      <para>
+          The language extension <option>-XBinaryLiterals</option>
+          adds support for expressing integer literals in binary
+          notation with the prefix <literal>0b</literal> or
+          <literal>0B</literal>. For instance, the binary integer
+          literal <literal>0b11001001</literal> will be desugared into
+          <literal>fromInteger 201</literal> when
+          <option>-XBinaryLiterals</option> is enabled.
+      </para>
+   </sect2>
 
     <!-- ====================== HIERARCHICAL MODULES =======================  -->
 
@@ -857,8 +877,8 @@
 
 <para>
 Pattern synonyms are enabled by the flag
-<literal>-XPatternSynonyms</literal>, which is required for both
-defining them <emphasis>and</emphasis> using them.  More information
+<literal>-XPatternSynonyms</literal>, which is required for defining
+them, but <emphasis>not</emphasis> for using them.  More information
 and examples of view patterns can be found on the <ulink
 url="http://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms">Wiki
 page</ulink>.
@@ -967,143 +987,216 @@
 In this case, <literal>Head</literal> <replaceable>x</replaceable>
 cannot be used in expressions, only patterns, since it wouldn't
 specify a value for the <replaceable>xs</replaceable> on the
-right-hand side.
+right-hand side. We can give an explicit inversion of a pattern
+synonym using the following syntax:
 </para>
 
-<para>
-The semantics of a unidirectional pattern synonym declaration and
-usage are as follows:
+<programlisting>
+  pattern Head x &lt;- x:xs where
+    Head x = [x]
+</programlisting>
 
-<itemizedlist>
+<para>
+The syntax and semantics of pattern synonyms are elaborated in the
+following subsections.
+See the <ulink
+url="http://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms">Wiki
+page</ulink> for more details.
+</para>
 
-<listitem> Syntax:
+<sect3> <title>Syntax and scoping of pattern synonyms</title>
 <para>
 A pattern synonym declaration can be either unidirectional or
 bidirectional. The syntax for unidirectional pattern synonyms is:
-</para>
 <programlisting>
   pattern Name args &lt;- pat
 </programlisting>
-<para>
   and the syntax for bidirectional pattern synonyms is:
-</para>
 <programlisting>
   pattern Name args = pat
+</programlisting> or
+<programlisting>
+  pattern Name args &lt;- pat where
+    Name args = expr
 </programlisting>
+  Either prefix or infix syntax can be
+  used.
+</para>
 <para>
   Pattern synonym declarations can only occur in the top level of a
   module. In particular, they are not allowed as local
-  definitions. Currently, they also don't work in GHCi, but that is a
-  technical restriction that will be lifted in later versions.
+  definitions.
+</para>
+<para>
+  The variables in the left-hand side of the definition are bound by
+  the pattern on the right-hand side. For implicitly bidirectional
+  pattern synonyms, all the variables of the right-hand side must also
+  occur on the left-hand side; also, wildcard patterns and view
+  patterns are not allowed. For unidirectional and
+  explicitly-bidirectional pattern synonyms, there is no restriction
+  on the right-hand side pattern.
+</para>
+
+<para>
+  Pattern synonyms cannot be defined recursively.
 </para>
+</sect3>
+
+<sect3 id="patsyn-impexp"> <title>Import and export of pattern synonyms</title>
+
 <para>
   The name of the pattern synonym itself is in the same namespace as
-  proper data constructors. Either prefix or infix syntax can be
-  used. In export/import specifications, you have to prefix pattern
+  proper data constructors. In an export or import specification,
+  you must prefix pattern
   names with the <literal>pattern</literal> keyword, e.g.:
-</para>
 <programlisting>
   module Example (pattern Single) where
   pattern Single x = [x]
 </programlisting>
-</listitem>
-
-<listitem> Scoping:
-
-<para>
-  The variables in the left-hand side of the definition are bound by
-  the pattern on the right-hand side. For bidirectional pattern
-  synonyms, all the variables of the right-hand side must also occur
-  on the left-hand side; also, wildcard patterns and view patterns are
-  not allowed. For unidirectional pattern synonyms, there is no
-  restriction on the right-hand side pattern.
+Without the <literal>pattern</literal> prefix, <literal>Single</literal> would
+be interpreted as a type constructor in the export list.
 </para>
-
 <para>
-  Pattern synonyms cannot be defined recursively.
+You may also use the <literal>pattern</literal> keyword in an import/export
+specification to import or export an ordinary data constructor.  For example:
+<programlisting>
+  import Data.Maybe( pattern Just )
+</programlisting>
+would bring into scope the data constructor <literal>Just</literal> from the
+<literal>Maybe</literal> type, without also bringing the type constructor
+<literal>Maybe</literal> into scope.
 </para>
+</sect3>
 
-</listitem>
-
-<listitem> Typing:
+<sect3> <title>Typing of pattern synonyms</title>
 
 <para>
   Given a pattern synonym definition of the form
-</para>
 <programlisting>
   pattern P var1 var2 ... varN &lt;- pat
 </programlisting>
-<para>
   it is assigned a <emphasis>pattern type</emphasis> of the form
-</para>
 <programlisting>
-  pattern CProv => P t1 t2 ... tN :: CReq => t
+  pattern P :: CProv => CReq => t1 -> t2 -> ... -> tN -> t
 </programlisting>
-<para>
   where <replaceable>CProv</replaceable> and
   <replaceable>CReq</replaceable> are type contexts, and
   <replaceable>t1</replaceable>, <replaceable>t2</replaceable>, ...,
   <replaceable>tN</replaceable> and <replaceable>t</replaceable> are
   types.
-</para>
-
-<para>
-A pattern synonym of this type can be used in a pattern if the
-instatiated (monomorphic) type satisfies the constraints of
-<replaceable>CReq</replaceable>. In this case, it extends the context
-available in the right-hand side of the match with
-<replaceable>CProv</replaceable>, just like how an existentially-typed
-data constructor can extend the context.
-</para>
-
-<para>
-For example, in the following program:
-</para>
+Notice the unusual form of the type, with two contexts <replaceable>CProv</replaceable> and <replaceable>CReq</replaceable>:
+<itemizedlist>
+<listitem><para><replaceable>CReq</replaceable> are the constraints <emphasis>required</emphasis> to match the pattern.</para></listitem>
+<listitem><para><replaceable>CProv</replaceable> are the constraints <emphasis>made available (provided)</emphasis>
+by a successful pattern match.</para></listitem>
+</itemizedlist>
+For example, consider
 <programlisting>
-{-# LANGUAGE PatternSynonyms, GADTs #-}
-module ShouldCompile where
-
 data T a where
-	MkT :: (Show b) => a -> b -> T a
+  MkT :: (Show b) => a -> b -> T a
 
-pattern ExNumPat x = MkT 42 x
-</programlisting>
+f1 :: (Eq a, Num a) => MkT a -> String
+f1 (MkT 42 x) = show x
 
-<para>
-the pattern type of <literal>ExNumPat</literal> is
-</para>
+pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a
+pattern ExNumPat x = MkT 42 x
 
-<programlisting>
-pattern (Show b) => ExNumPat b :: (Num a, Eq a) => T a
+f2 :: (Eq a, Num a) => MkT a -> String
+f2 (ExNumPat x) = show x
 </programlisting>
-
+Here <literal>f1</literal> does not use pattern synonyms.  To match against the
+numeric pattern <literal>42</literal> <emphasis>requires</emphasis> the caller to
+satisfy the constraints <literal>(Num a, Eq a)</literal>,
+so they appear in <literal>f1</literal>'s type.  The call to <literal>show</literal> generates a <literal>(Show b)</literal>
+constraint, where <literal>b</literal> is an existentially type variable bound by the pattern match
+on <literal>MkT</literal>. But the same pattern match also <emphasis>provides</emphasis> the constraint
+<literal>(Show b)</literal> (see <literal>MkT</literal>'s type), and so all is well.
+</para>
 <para>
-  and so can be used in a function definition like the following:
+Exactly the same reasoning applies to <literal>ExNumPat</literal>:
+matching against <literal>ExNumPat</literal> <emphasis>requires</emphasis> 
+the constraints <literal>(Num a, Eq a)</literal>, and <emphasis>provides</emphasis>
+the constraint <literal>(Show b)</literal>.
 </para>
+<para>
+Note also the following points
+<itemizedlist>
+<listitem><para>
+In the common case where <replaceable>CReq</replaceable> is empty,
+  <literal>()</literal>, it can be omitted altogether.
+</para> </listitem>
 
+<listitem><para>
+You may specify an explicit <emphasis>pattern signature</emphasis>, as
+we did for <literal>ExNumPat</literal> above, to specify the type of a pattern,
+just as you can for a function.  As usual, the type signature can be less polymorphic
+than the inferred type.  For example
 <programlisting>
-  f :: (Num t, Eq t) => T t -> String
-  f (ExNumPat x) = show x
+  -- Inferred type would be 'a -> [a]'
+  pattern SinglePair :: (a, a) -> [(a, a)]
+  pattern SinglePair x = [x]
 </programlisting>
+</para> </listitem>
 
-<para>
-  For bidirectional pattern synonyms, uses as expressions have the type
-</para>
+<listitem><para>
+The GHCi <literal>:info</literal> command shows pattern types in this format.
+</para> </listitem>
+
+<listitem><para>
+For a bidirectional pattern synonym, a use of the pattern synonym as an expression has the type
 <programlisting>
   (CProv, CReq) => t1 -> t2 -> ... -> tN -> t
 </programlisting>
-
-<para>
-  So in the previous example, <literal>ExNumPat</literal>,
-  when used in an expression, has type
-</para>
+  So in the previous example, when used in an expression, <literal>ExNumPat</literal> has type
 <programlisting>
   ExNumPat :: (Show b, Num a, Eq a) => b -> T t
 </programlisting>
+Notice that this is a tiny bit more restrictive than the expression <literal>MkT 42 x</literal>
+which would not require <literal>(Eq a)</literal>.
+</para> </listitem>
 
-</listitem>
+<listitem><para>
+Consider these two pattern synonyms:
+<programlisting>
+data S a where
+   S1 :: Bool -> S Bool
 
-<listitem> Matching:
+pattern P1 b = Just b  -- P1 ::             Bool -> Maybe Bool
+pattern P2 b = S1 b    -- P2 :: (b~Bool) => Bool -> S b
+
+f :: Maybe a -> String
+f (P1 x) = "no no no"     -- Type-incorrect
+
+g :: S a -> String
+g (P2 b) = "yes yes yes"  -- Fine
+</programlisting>
+Pattern <literal>P1</literal> can only match against a value of type <literal>Maybe Bool</literal>,
+so function <literal>f</literal> is rejected because the type signature is <literal>Maybe a</literal>.
+(To see this, imagine expanding the pattern synonym.)
+</para>
+<para>
+On the other hand, function <literal>g</literal> works fine, becuase matching against <literal>P2</literal>
+(which wraps the GADT <literal>S</literal>) provides the local equality <literal>(a~Bool)</literal>.
+If you were to give an explicit pattern signature <literal>P2 :: Bool -> S Bool</literal>, then <literal>P2</literal>
+would become less polymorphic, and would behave exactly like <literal>P1</literal> so that <literal>g</literal>
+would then be rejected.
+</para>
+<para>
+In short, if you want GADT-like behaviour for pattern synonyms,
+then (unlike unlike concrete data constructors like <literal>S1</literal>)
+you must write its type with explicit provided equalities.
+For a concrete data construoctr like <literal>S1</literal> you can write
+its type signature as eigher <literal>S1 :: Bool -> S Bool</literal> or
+<literal>S1 :: (b~Bool) => Bool -> S b</literal>; the two are equivalent.
+Not so for pattern synonyms: the two forms are different, in order to
+distinguish the two cases above. (See <ulink url="https://ghc.haskell.org/trac/ghc/ticket/9953">Trac #9953</ulink> for
+discussion of this choice.)
+</para></listitem>
+</itemizedlist>
+</para>
+</sect3>
+
+<sect3><title>Matching of pattern synonyms</title>
 
 <para>
 A pattern synonym occurrence in a pattern is evaluated by first
@@ -1119,14 +1212,12 @@
 f _                = False
 
 f' [x, y] | True &lt;- x, True &lt;- y = True
-f' _                                   = False
+f' _                              = False
 </programlisting>
 
 <para>
   Note that the strictness of <literal>f</literal> differs from that
   of <literal>g</literal> defined below:
-</para>
-
 <programlisting>
 g [True, True] = True
 g _            = False
@@ -1136,9 +1227,8 @@
 *Main> g (False:undefined)
 False
 </programlisting>
-</listitem>
-</itemizedlist>
 </para>
+</sect3>
 
 </sect2>
 
@@ -1883,7 +1973,8 @@
 	      functions <literal>(>>=)</literal>,
 	      <literal>(>>)</literal>, and <literal>fail</literal>,
 	      are in scope (not the Prelude
-	      versions).  List comprehensions, mdo (<xref linkend="recursive-do-notation"/>), and parallel array
+	      versions).  List comprehensions, <literal>mdo</literal>
+	      (<xref linkend="recursive-do-notation"/>), and parallel array
 	      comprehensions, are unaffected.  </para></listitem>
 
 	      <listitem>
@@ -2284,8 +2375,8 @@
 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
+Record wildcards in patterns 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>
 bindings and at the top-level.  For example, the top-level binding
@@ -2297,7 +2388,7 @@
 </para></listitem>
 
 <listitem><para>
-Record wildcards can also be used in expressions, writing, for example,
+Record wildcards can also be used in an expression, when constructing a record.  For example,
 <programlisting>
 let {a = 1; b = 2; c = 3; d = 4} in C {..}
 </programlisting>
@@ -2311,7 +2402,15 @@
 </para></listitem>
 
 <listitem><para>
-The "<literal>..</literal>" expands to the missing
+Record wildcards may <emphasis>not</emphasis> be used in record <emphasis>updates</emphasis>.  For example this
+is illegal:
+<programlisting>
+f r = r { x = 3, .. }
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+For both pattern and expression wildcards, the "<literal>..</literal>" expands to the missing
 <emphasis>in-scope</emphasis> record fields.
 Specifically the expansion of "<literal>C {..}</literal>" includes
 <literal>f</literal> if and only if:
@@ -2328,6 +2427,8 @@
 apart from the binding of the record selector itself.
 </para></listitem>
 </itemizedlist>
+These rules restrict record wildcards to the situations in which the user
+could have written the expanded version.
 For example
 <programlisting>
 module M where
@@ -2342,6 +2443,18 @@
 is not in scope (apart from the binding of the
 record selector <literal>c</literal>, of course).
 </para></listitem>
+
+<listitem><para>
+Record wildcards cannot be used (a) in a record update construct, and (b) for data
+constructors that are not declared with record fields.  For example:
+<programlisting>
+f x = x { v=True, .. }   -- Illegal (a)
+
+data T = MkT Int Bool
+g = MkT { .. }           -- Illegal (b)
+h (MkT { .. }) = True    -- Illegal (b)
+</programlisting>
+</para></listitem>
 </itemizedlist>
 </para>
 
@@ -2391,7 +2504,36 @@
 </sect2>
 
 <sect2 id="package-imports">
-  <title>Package-qualified imports</title>
+<title>Import and export extensions</title>
+
+<sect3>
+  <title>Hiding things the imported module doesn't export</title>
+
+<para>
+Technically in Haskell 2010 this is illegal:
+<programlisting>
+module A( f ) where
+  f = True
+
+module B where
+  import A hiding( g )  -- A does not export g
+  g = f
+</programlisting>
+The <literal>import A hiding( g )</literal> in module <literal>B</literal>
+is technically an error (<ulink url="http://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1020005.3.1">Haskell Report, 5.3.1</ulink>)
+because <literal>A</literal> does not export <literal>g</literal>.
+However GHC allows it, in the interests of supporting backward compatibility; for example, a newer version of
+<literal>A</literal> might export <literal>g</literal>, and you want <literal>B</literal> to work
+in either case.
+</para>
+<para>
+The warning <literal>-fwarn-dodgy-imports</literal>, which is off by default but included with <literal>-W</literal>,
+warns if you hide something that the imported module does not export.
+</para>
+</sect3>
+
+<sect3>
+  <title id="package-qualified-imports">Package-qualified imports</title>
 
   <para>With the <option>-XPackageImports</option> flag, GHC allows
   import declarations to be qualified by the package name that the
@@ -2414,10 +2556,12 @@
     added mainly so that we can build backwards-compatible versions of
     packages when APIs change.  It can lead to fragile dependencies in
     the common case: modules occasionally move from one package to
-    another, rendering any package-qualified imports broken.</para>
-</sect2>
+    another, rendering any package-qualified imports broken.
+    See also <xref linkend="package-thinning-and-renaming" /> for
+    an alternative way of disambiguating between module names.</para>
+</sect3>
 
-<sect2 id="safe-imports-ext">
+<sect3 id="safe-imports-ext">
   <title>Safe imports</title>
 
   <para>With the <option>-XSafe</option>, <option>-XTrustworthy</option>
@@ -2435,15 +2579,15 @@
     safely imported. For a description of when a import is
     considered safe see <xref linkend="safe-haskell"/></para>
 
-</sect2>
+</sect3>
 
-<sect2 id="explicit-namespaces">
+<sect3 id="explicit-namespaces">
 <title>Explicit namespaces in import/export</title>
 
-<para> In an import or export list, such as 
+<para> In an import or export list, such as
 <programlisting>
   module M( f, (++) ) where ...
-    import N( f, (++) ) 
+    import N( f, (++) )
     ...
 </programlisting>
 the entities <literal>f</literal> and <literal>(++)</literal> are <emphasis>values</emphasis>.
@@ -2452,12 +2596,12 @@
 case, how would you export or import it?
 </para>
 <para>
-The <option>-XExplicitNamespaces</option> extension allows you to prefix the name of 
-a type constructor in an import or export list with "<literal>type</literal>" to 
+The <option>-XExplicitNamespaces</option> extension allows you to prefix the name of
+a type constructor in an import or export list with "<literal>type</literal>" to
 disambiguate this case, thus:
 <programlisting>
   module M( f, type (++) ) where ...
-    import N( f, type (++) ) 
+    import N( f, type (++) )
     ...
   module N( f, type (++) ) where
     data family a ++ b = L a | R b
@@ -2465,6 +2609,14 @@
 The extension <option>-XExplicitNamespaces</option>
 is implied by <option>-XTypeOperators</option> and (for some reason) by <option>-XTypeFamilies</option>.
 </para>
+<para>
+In addition, with <option>-XPatternSynonyms</option> you can prefix the name of
+a data constructor in an import or export list with the keyword <literal>pattern</literal>,
+to allow the import or export of a data constructor without its parent type constructor
+(see <xref linkend="patsyn-impexp"/>).
+</para>
+</sect3>
+
 </sect2>
 
 <sect2 id="syntax-stolen">
@@ -2688,8 +2840,11 @@
 to be written infix, very much like expressions.  More specifically:
 <itemizedlist>
 <listitem><para>
-  A type constructor or class can be an operator, beginning with a colon; e.g. <literal>:*:</literal>.
-  The lexical syntax is the same as that for data constructors.
+  A type constructor or class can be any non-reserved operator.
+  Symbols used in types are always like capitalized identifiers; they
+  are never variables. Note that this is different from the lexical
+  syntax of data constructors, which are required to begin with a
+  <literal>:</literal>.
   </para></listitem>
 <listitem><para>
   Data type and type-synonym declarations can be written infix, parenthesised
@@ -2753,11 +2908,11 @@
 The language <option>-XTypeOperators</option> changes this behaviour:
 <itemizedlist>
 <listitem><para>
-Operator symbols become type <emphasis>constructors</emphasis> rather than 
+Operator symbols become type <emphasis>constructors</emphasis> rather than
 type <emphasis>variables</emphasis>.
 </para></listitem>
 <listitem><para>
-Operator symbols in types can be written infix, both in definitions and uses. 
+Operator symbols in types can be written infix, both in definitions and uses.
 for example:
 <programlisting>
 data a + b = Plus a b
@@ -2766,8 +2921,8 @@
 </para></listitem>
 <listitem><para>
 There is now some potential ambiguity in import and export lists; for example
-if you write <literal>import M( (+) )</literal> do you mean the 
-<emphasis>function</emphasis> <literal>(+)</literal> or the 
+if you write <literal>import M( (+) )</literal> do you mean the
+<emphasis>function</emphasis> <literal>(+)</literal> or the
 <emphasis>type constructor</emphasis> <literal>(+)</literal>?
 The default is the former, but with <option>-XExplicitNamespaces</option> (which is implied
 by <option>-XExplicitTypeOperators</option>) GHC allows you to specify the latter
@@ -3623,12 +3778,13 @@
 Tim Sheard. There is a longer introduction
 <ulink url="http://www.haskell.org/haskellwiki/GADT">on the wiki</ulink>,
 and Ralf Hinze's
-<ulink url="http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf">Fun with phantom types</ulink> also has a number of examples. Note that papers
+<ulink url="http://www.cs.ox.ac.uk/ralf.hinze/publications/With.pdf">Fun with phantom types</ulink> also has a number of examples. Note that papers
 may use different notation to that implemented in GHC.
 </para>
 <para>
 The rest of this section outlines the extensions to GHC that support GADTs.   The extension is enabled with
-<option>-XGADTs</option>.  The <option>-XGADTs</option> flag also sets <option>-XRelaxedPolyRec</option>.
+<option>-XGADTs</option>.  The <option>-XGADTs</option> flag also sets <option>-XGADTSyntax</option>
+and <option>-XMonoLocalBinds</option>.
 <itemizedlist>
 <listitem><para>
 A GADT can only be declared using GADT-style syntax (<xref linkend="gadt-style"/>);
@@ -3809,6 +3965,13 @@
 because <literal>T</literal> is a GADT, but you <emphasis>can</emphasis> generate
 the instance declaration using stand-alone deriving.
 </para>
+<para>
+The down-side is that,
+if the boilerplate code fails to typecheck, you will get an error message about that
+code, which you did not write.  Whereas, with a <literal>deriving</literal> clause
+the side-conditions are necessarily more conservative, but any error message
+may be more comprehensible.
+</para>
 </listitem>
 </itemizedlist></para>
 
@@ -3837,9 +4000,8 @@
 
 </sect2>
 
-
-<sect2 id="deriving-typeable">
-<title>Deriving clause for extra classes (<literal>Typeable</literal>, <literal>Data</literal>, etc)</title>
+<sect2 id="deriving-extra">
+<title>Deriving instances of extra classes (<literal>Data</literal>, etc)</title>
 
 <para>
 Haskell 98 allows the programmer to add "<literal>deriving( Eq, Ord )</literal>" to a data type
@@ -3851,27 +4013,6 @@
 <para>
 GHC extends this list with several more classes that may be automatically derived:
 <itemizedlist>
-<listitem><para> With <option>-XDeriveDataTypeable</option>, you can derive instances of the classes
-<literal>Typeable</literal>, and <literal>Data</literal>, defined in the library
-modules <literal>Data.Typeable</literal> and <literal>Data.Data</literal> respectively.
-</para>
-<para>Since GHC 7.8.1, <literal>Typeable</literal> is kind-polymorphic (see
-<xref linkend="kind-polymorphism"/>) and can be derived for any datatype and
-type class. Instances for datatypes can be derived by attaching a
-<literal>deriving Typeable</literal> clause to the datatype declaration, or by
-using standalone deriving (see <xref linkend="stand-alone-deriving"/>).
-Instances for type classes can only be derived using standalone deriving.
-For data families, <literal>Typeable</literal> should only be derived for the
-uninstantiated family type; each instance will then automatically have a
-<literal>Typeable</literal> instance too.
-See also <xref linkend="auto-derive-typeable"/>.
-</para>
-<para>
-Also since GHC 7.8.1, handwritten (ie. not derived) instances of
-<literal>Typeable</literal> are forbidden, and will result in an error.
-</para>
-</listitem>
-
 <listitem><para> With <option>-XDeriveGeneric</option>, you can derive
 instances of the classes <literal>Generic</literal> and
 <literal>Generic1</literal>, defined in <literal>GHC.Generics</literal>.
@@ -3884,6 +4025,12 @@
 defined in <literal>GHC.Base</literal>.
 </para></listitem>
 
+<listitem><para> With <option>-XDeriveDataTypeable</option>, you can derive instances of
+the class <literal>Data</literal>,
+defined in <literal>Data.Data</literal>.  See <xref linkend="deriving-typeable"/> for
+deriving <literal>Typeable</literal>.
+</para></listitem>
+
 <listitem><para> With <option>-XDeriveFoldable</option>, you can derive instances of
 the class <literal>Foldable</literal>,
 defined in <literal>Data.Foldable</literal>.
@@ -3891,24 +4038,78 @@
 
 <listitem><para> With <option>-XDeriveTraversable</option>, you can derive instances of
 the class <literal>Traversable</literal>,
-defined in <literal>Data.Traversable</literal>.
+defined in <literal>Data.Traversable</literal>. Since the <literal>Traversable</literal>
+instance dictates the instances of <literal>Functor</literal> and
+<literal>Foldable</literal>, you'll probably want to derive them too, so
+<option>-XDeriveTraversable</option> implies
+<option>-XDeriveFunctor</option> and <option>-XDeriveFoldable</option>.
 </para></listitem>
 </itemizedlist>
+You can also use a standalone deriving declaration instead
+(see <xref linkend="stand-alone-deriving"/>).
+</para>
+<para>
 In each case the appropriate class must be in scope before it
 can be mentioned in the <literal>deriving</literal> clause.
 </para>
 </sect2>
 
-<sect2 id="auto-derive-typeable">
-<title>Automatically deriving <literal>Typeable</literal> instances</title>
+<sect2 id="deriving-typeable">
+<title>Deriving <literal>Typeable</literal> instances</title>
+
+<para>The class <literal>Typeable</literal> is very special:
+<itemizedlist>
+<listitem><para>
+<literal>Typeable</literal> is kind-polymorphic (see
+<xref linkend="kind-polymorphism"/>).
+</para></listitem>
+
+<listitem><para>
+GHC has a custom solver for discharging constraints that involve
+class <literal>Typeable</literal>, and handwritten instances are forbidden.
+This ensures that the programmer cannot subert the type system by
+writing bogus instances.
+</para></listitem>
+
+<listitem><para>
+Derived instances of <literal>Typeable</literal> are ignored,
+and may be reported as an error in a later version of the compiler.
+</para></listitem>
+
+<listitem><para>
+The rules for solving `Typeable` constraints are as follows:
+<itemizedlist>
+<listitem><para>A concrete type constructor applied to some types.
+<programlisting>
+instance (Typeable t1, .., Typeable t_n) =>
+  Typeable (T t1 .. t_n)
+</programlisting>
+This rule works for any concrete type constructor, including type
+constructors with polymorhic kinds.   The only restriction is that
+if the type constructor has a polymorhic kind, then it has to be applied
+to all of its kinds parameters, and these kinds need to be concrete
+(i.e., they cannot mention kind variables).
+</para></listitem>
+
+<listitem><para>
+<programlisting>A type variable applied to some types.
+instance (Typeable f, Typeable t1, .., Typeable t_n) =>
+  Typeable (f t1 .. t_n)
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+<programlisting>A concrete type literal.
+instance Typeable 0       -- Type natural literals
+instance Typeable "Hello" -- Type-level symbols
+</programlisting>
+</para></listitem>
+</itemizedlist>
+</para></listitem>
+
+
+</itemizedlist>
 
-<para>
-The flag <option>-XAutoDeriveTypeable</option> triggers the generation
-of derived <literal>Typeable</literal> instances for every datatype and type
-class declaration in the module it is used. It will also generate
-<literal>Typeable</literal> instances for any promoted data constructors
-(<xref linkend="promotion"/>). This flag implies
-<option>-XDeriveDataTypeable</option> (<xref linkend="deriving-typeable"/>).
 </para>
 
 </sect2>
@@ -4034,47 +4235,52 @@
 
 <sect3> <title> A more precise specification </title>
 <para>
-Derived instance declarations are constructed as follows. Consider the
-declaration (after expansion of any type synonyms)
+A derived instance is derived only for declarations of these forms (after expansion of any type synonyms)
 
 <programlisting>
-  newtype T v1...vn = T' (t vk+1...vn) deriving (c1...cm)
+  newtype T v1..vn                   = MkT (t vk+1..vn) deriving (C t1..tj)
+  newtype instance T s1..sk vk+1..vn = MkT (t vk+1..vn) deriving (C t1..tj)
 </programlisting>
-
 where
  <itemizedlist>
 <listitem><para>
-  The <literal>ci</literal> are partial applications of
-  classes of the form <literal>C t1'...tj'</literal>, where the arity of <literal>C</literal>
+<literal>v1..vn</literal> are type variables, and <literal>t</literal>,
+<literal>s1..sk</literal>, <literal>t1..tj</literal> are types.
+</para></listitem>
+<listitem><para>
+  The <literal>(C t1..tj)</literal> is a partial applications of the class <literal>C</literal>,
+  where the arity of <literal>C</literal>
   is exactly <literal>j+1</literal>.  That is, <literal>C</literal> lacks exactly one type argument.
 </para></listitem>
 <listitem><para>
-  The <literal>k</literal> is chosen so that <literal>ci (T v1...vk)</literal> is well-kinded.
+  <literal>k</literal> is chosen so that <literal>C t1..tj (T v1...vk)</literal> is well-kinded.
+(Or, in the case of a <literal>data instance</literal>, so that <literal>C t1..tj (T s1..sk)</literal> is
+well kinded.)
 </para></listitem>
 <listitem><para>
   The type <literal>t</literal> is an arbitrary type.
 </para></listitem>
 <listitem><para>
-  The type variables <literal>vk+1...vn</literal> do not occur in <literal>t</literal>,
-  nor in the <literal>ci</literal>, and
+  The type variables <literal>vk+1...vn</literal> do not occur in the types <literal>t</literal>,
+  <literal>s1..sk</literal>, or <literal>t1..tj</literal>.
 </para></listitem>
 <listitem><para>
-  None of the <literal>ci</literal> is <literal>Read</literal>, <literal>Show</literal>,
+  <literal>C</literal> is not <literal>Read</literal>, <literal>Show</literal>,
 		<literal>Typeable</literal>, or <literal>Data</literal>.  These classes
 		should not "look through" the type or its constructor.  You can still
 		derive these classes for a newtype, but it happens in the usual way, not
 		via this new mechanism.
 </para></listitem>
 <listitem><para>
-  It is safe to coerce each of the methods of <literal>ci</literal>. That is,
-  the missing last argument to each of the <literal>ci</literal> is not used
-  at a nominal role in any of the <literal>ci</literal>'s methods.
+  It is safe to coerce each of the methods of <literal>C</literal>. That is,
+  the missing last argument to <literal>C</literal> is not used
+  at a nominal role in any of the <literal>C</literal>'s methods.
   (See <xref linkend="roles"/>.)</para></listitem>
 </itemizedlist>
-Then, for each <literal>ci</literal>, the derived instance
+Then the derived instance is of form
 declaration is:
 <programlisting>
-  instance ci t => ci (T v1...vk)
+  instance C t1..tj t => C t1..tj (T v1...vk)
 </programlisting>
 As an example which does <emphasis>not</emphasis> work, consider
 <programlisting>
@@ -4116,6 +4322,25 @@
 </para>
 </sect3>
 </sect2>
+
+<sect2 id="derive-any-class">
+<title>Deriving any other class</title>
+
+<para>
+With <option>-XDeriveAnyClass</option> you can derive any other class. The
+compiler will simply generate an empty instance. The instance context will be
+generated according to the same rules used when deriving <literal>Eq</literal>.
+This is mostly useful in classes whose <link linkend="minimal-pragma">minimal
+set</link> is empty, and especially when writing
+<link linkend="generic-programming">generic functions</link>.
+
+In case you try to derive some class on a newtype, and
+<option>-XGeneralizedNewtypeDeriving</option> is also on,
+<option>-XDeriveAnyClass</option> takes precedence.
+</para>
+
+</sect2>
+
 </sect1>
 
 
@@ -4276,7 +4501,9 @@
 
 <sect3 id="nullary-type-classes">
 <title>Nullary type classes</title>
-Nullary (no parameter) type classes are enabled with <option>-XNullaryTypeClasses</option>.
+Nullary (no parameter) type classes are enabled with
+<option>-XMultiTypeClasses</option>; historically, they were enabled with the
+(now deprecated) <option>-XNullaryTypeClasses</option>.
 Since there are no available parameters, there can be at most one instance
 of a nullary class. A nullary type class might be used to document some assumption
 in a type signature (such as reliance on the Riemann hypothesis) or add some
@@ -4887,6 +5114,11 @@
 with <option>-fcontext-stack=</option><emphasis>N</emphasis>.
 </para>
 
+<para>
+The <option>-XUndecidableInstances</option> flag is also used to lift some of the
+restricitions imposed on type family instances. See <xref linkend="type-family-decidability"/>.
+</para>
+
 </sect3>
 
 
@@ -4897,40 +5129,128 @@
 In general, as discussed in <xref linkend="instance-resolution"/>,
 <emphasis>GHC requires 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>-XOverlappingInstances</option>
+should be used to resolve a type-class constraint</emphasis>.
+GHC also provides a way to to loosen
+the instance resolution, by
+allowing more than one instance to match, <emphasis>provided there is a most
+specific one</emphasis>.  Moreover, it can be loosened further, by allowing more than one instance to match
+irespective of whether there is a most specific one.
+This section gives the details.
+</para>
+<para>
+To control the choice of instance, it is possible to specify the overlap behavior for individual
+instances with a pragma, written immediately after the
+<literal>instance</literal> keyword.  The pragma may be one of:
+<literal>{-# OVERLAPPING #-}</literal>,
+<literal>{-# OVERLAPPABLE #-}</literal>,
+<literal>{-# OVERLAPS #-}</literal>,
+or <literal>{-# INCOHERENT #-}</literal>.
+</para>
+<para>
+The matching behaviour is also influenced by two module-level language extension flags: <option>-XOverlappingInstances</option>
 <indexterm><primary>-XOverlappingInstances
 </primary></indexterm>
 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>LANGUAGE</literal> pragma if desired (<xref linkend="language-pragma"/>).</para>
+</primary></indexterm>.   These flags are now deprecated (since GHC 7.10) in favour of
+the fine-grained per-instance pragmas.
+</para>
+
 <para>
-The <option>-XOverlappingInstances</option> flag instructs GHC to loosen
-the instance resolution described in <xref linkend="instance-resolution"/>, by
-allowing more than one instance to match, <emphasis>provided there is a most
-specific one</emphasis>. The <option>-XIncoherentInstances</option> flag
-further loosens the resolution, by allowing more than one instance to match,
-irespective of whether there is a most specific one.
+A more precise specification is as follows.
+The willingness to be overlapped or incoherent is a property of
+the <emphasis>instance declaration</emphasis> itself, controlled as follows:
+<itemizedlist>
+<listitem><para>An instance is <emphasis>incoherent</emphasis> if: it has an <literal>INCOHERENT</literal> pragma; or if the instance has no pragma and it appears in a module compiled with <literal>-XIncoherentInstances</literal>.
+</para></listitem>
+<listitem><para>An instance is <emphasis>overlappable</emphasis> if: it has an <literal>OVERLAPPABLE</literal> or <literal>OVERLAPS</literal> pragma; or if the instance has no pragma and it appears in a module compiled with <literal>-XOverlappingInstances</literal>; or if the instance is incoherent.
+</para></listitem>
+<listitem><para>An instance is <emphasis>overlapping</emphasis> if: it has an <literal>OVERLAPPING</literal> or <literal>OVERLAPS</literal> pragma; or if the instance has no pragma and it appears in a module compiled with <literal>-XOverlappingInstances</literal>; or if the instance is incoherent.
+</para></listitem>
+</itemizedlist>
 </para>
 
 <para>
-For example, consider
+Now suppose that, in some client module, we are searching for an instance of the
+<emphasis>target constraint</emphasis> <literal>(C ty1 .. tyn)</literal>.
+The search works like this.
+<itemizedlist>
+<listitem><para>
+Find all instances I that <emphasis>match</emphasis> the target constraint;
+that is, the target constraint is a substitution instance of I.  These
+instance declarations are the <emphasis>candidates</emphasis>.
+</para></listitem>
+
+<listitem><para>
+Eliminate any candidate IX for which both of the following hold:
+
+<itemizedlist>
+  <listitem><para>There is another candidate IY that is strictly more specific;
+    that is, IY is a substitution instance of IX but not vice versa.
+  </para></listitem>
+  <listitem><para>
+  Either IX is <emphasis>overlappable</emphasis>, or IY is
+  <emphasis>overlapping</emphasis>.  (This "either/or" design, rather than a "both/and" design,
+  allow a client to deliberately override an instance from a library, without requiring a change to the library.)
+  </para></listitem>
+  </itemizedlist>
+</para>
+</listitem>
+
+<listitem><para>
+If exactly one non-incoherent candidate remains, select it.  If all
+remaining candidates are incoherent, select an arbitary
+one. Otherwise the search fails (i.e. when more than one surviving candidate is not incoherent).
+</para></listitem>
+
+<listitem><para>
+If the selected candidate (from the previous step) is incoherent, the search succeeds, returning that candidate.
+</para></listitem>
+
+<listitem><para>
+If not, find all instances that <emphasis>unify</emphasis> with the target
+constraint, but do not <emphasis>match</emphasis> it.
+Such non-candidate instances might match when the target constraint is further
+instantiated.  If all of them are incoherent, the search succeeds, returning the selected candidate;
+if not, the search fails.
+</para></listitem>
+
+</itemizedlist>
+Notice that these rules are not influenced by flag settings in the client module, where
+the instances are <emphasis>used</emphasis>.
+These rules make it possible for a library author to design a library that relies on
+overlapping instances without the client having to know.
+</para>
+<para>
+Errors are reported <emphasis>lazily</emphasis> (when attempting to solve a constraint), rather than <emphasis>eagerly</emphasis>
+(when the instances themselves are defined).  Consider, for example
 <programlisting>
-  instance context1 => C Int b     where ...  -- (A)
-  instance context2 => C a   Bool  where ...  -- (B)
-  instance context3 => C a   [b]   where ...  -- (C)
-  instance context4 => C Int [Int] where ...  -- (D)
+  instance C Int  b where ..
+  instance C a Bool where ..
 </programlisting>
-compiled with <option>-XOverlappingInstances</option> enabled. The constraint
-<literal>C Int [Int]</literal> matches instances (A), (C) and (D), but the last
+These potentially overlap, but GHC will not complain about the instance declarations
+themselves, regardless of flag settings.  If we later try to solve the constraint
+<literal>(C Int Char)</literal> then only the first instance matches, and all is well.
+Similarly with <literal>(C Bool Bool)</literal>.  But if we try to solve <literal>(C Int Bool)</literal>,
+both instances match and an error is reported.
+</para>
+
+<para>
+As a more substantial example of the rules in action, consider
+<programlisting>
+  instance {-# OVERLAPPABLE #-} context1 => C Int b     where ...  -- (A)
+  instance {-# OVERLAPPABLE #-} context2 => C a   Bool  where ...  -- (B)
+  instance {-# OVERLAPPABLE #-} context3 => C a   [b]   where ...  -- (C)
+  instance {-# OVERLAPPING  #-} context4 => C Int [Int] where ...  -- (D)
+</programlisting>
+Now suppose that the type inference
+engine needs to solve the constraint
+<literal>C Int [Int]</literal>.  This constraint matches instances (A), (C) and (D), but the last
 is more specific, and hence is chosen.
 </para>
 <para>If (D) did not exist then (A) and (C) would still be matched, but neither is
-most specific. In that case, the program would be rejected even with
-<option>-XOverlappingInstances</option>. With
-<option>-XIncoherentInstances</option> enabled, it would be accepted and (A) or
+most specific. In that case, the program would be rejected, unless
+<option>-XIncoherentInstances</option> is enabled, in which case it would be accepted and (A) or
 (C) would be chosen arbitrarily.
 </para>
 <para>
@@ -4940,7 +5260,7 @@
 substituting <literal>a:=Int</literal>.
 </para>
 <para>
-However, GHC is conservative about committing to an overlapping instance.  For example:
+GHC is conservative about committing to an overlapping instance.  For example:
 <programlisting>
   f :: [b] -> [b]
   f x = ...
@@ -5037,60 +5357,10 @@
 would be to reject module <literal>Help</literal>
 on the grounds that a later instance declaration might overlap the local one.)
 </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>-XOverlappingInstances</option>
-and <option>-XIncoherentInstances</option> flags when that module is
-being defined.  Suppose we are searching for an instance of the 
-<emphasis>target constraint</emphasis> <literal>(C ty1 .. tyn)</literal>.
-The search works like this.
-<itemizedlist>
-<listitem><para>
-Find all instances I that <emphasis>match</emphasis> the target constraint;
-that is, the target constraint is a substitution instance of I.  These
-instance declarations are the <emphasis>candidates</emphasis>.
-</para></listitem>
-
-<listitem><para>
-Find all <emphasis>non-candidate</emphasis> instances 
-that <emphasis>unify</emphasis> with the target constraint.
-Such non-candidates instances might match when the target constraint is further
-instantiated.  If all of them were compiled with
-<option>-XIncoherentInstances</option>, proceed; if not, the search fails.
-</para></listitem>
-
-<listitem><para>
-Eliminate any candidate IX for which both of the following hold:
-
-<itemizedlist>
-<listitem><para>There is another candidate IY that is strictly more specific;
-that is, IY is a substitution instance of IX but not vice versa.
-</para></listitem>
-<listitem><para>Either IX or IY was compiled with 
-<option>-XOverlappingInstances</option>.
-</para></listitem>
-</itemizedlist>
-
-</para></listitem>
-
-<listitem><para>
-If only one candidate remains, pick it.
-Otherwise if all remaining candidates were compiled with
-<option>-XInccoherentInstances</option>, pick an arbitrary candidate.
-</para></listitem>
-
-</itemizedlist>
-These rules make it possible for a library author to design a library that relies on
-overlapping instances without the library client having to know.
-</para>
-<para>The <option>-XIncoherentInstances</option> flag implies the
-<option>-XOverlappingInstances</option> flag, but not vice versa.
-</para>
 </sect3>
 
 <sect3 id="instance-sigs">
-<title>Type signatures in instance declarations</title>
+<title>Instance signatures: type signatures in instance declarations</title>
 <para>In Haskell, you can't write a type signature in an instance declaration, but it
 is sometimes convenient to do so, and the language extension <option>-XInstanceSigs</option>
 allows you to do so.  For example:
@@ -5100,10 +5370,30 @@
     (==) :: T a -> T a -> Bool   -- The signature
     (==) (MkT x1 x2) (MkTy y1 y2) = x1==y1 &amp;&amp; x2==y2
 </programlisting>
-The type signature in the instance declaration must be precisely the same as
+</para>
+Some details
+<itemizedlist>
+<listitem><para>
+The type signature in the instance declaration must be more polymorphic than (or the same as)
 the one in the class declaration, instantiated with the instance type.
+For example, this is fine:
+<programlisting>
+  instance Eq a => Eq (T a) where
+     (==) :: forall b. b -> b -> Bool
+     (==) x y = True
+</programlisting>
+Here the signature in the instance declaration is more polymorphic than that
+required by the instantiated class method.
 </para>
-<para>
+</listitem>
+
+<listitem><para>
+The code for the method in the instance declaration is typechecked against the type signature
+supplied in the instance declaration, as you would expect. So if the instance signature
+is more polymorphic than required, the code must be too.
+</para></listitem>
+
+<listitem><para>
 One stylistic reason for wanting to write a type signature is simple documentation.  Another
 is that you may want to bring scoped type variables into scope.  For example:
 <programlisting>
@@ -5121,7 +5411,8 @@
 (<xref linkend="scoped-type-variables"/>),
 the <literal>forall b</literal> scopes over the definition of <literal>foo</literal>,
 and in particular over the type signature for <literal>xs</literal>.
-</para>
+</para></listitem>
+</itemizedlist>
 </sect3>
 
 </sect2>
@@ -5160,21 +5451,30 @@
 from module <literal>GHC.Exts</literal>.
 </para>
 <para>
-Haskell's defaulting mechanism is extended to cover string literals, when <option>-XOverloadedStrings</option> is specified.
+Haskell's defaulting mechanism (<ulink url="http://www.haskell.org/onlinereport/decls.html#sect4.3.4">Haskell Report, Section 4.3.4</ulink>)
+is extended to cover string literals, when <option>-XOverloadedStrings</option> is specified.
 Specifically:
 <itemizedlist>
 <listitem><para>
-Each type in a default declaration must be an
+Each type in a <literal>default</literal> declaration must be an
 instance of <literal>Num</literal> <emphasis>or</emphasis> of <literal>IsString</literal>.
 </para></listitem>
 
 <listitem><para>
-The standard defaulting rule (<ulink url="http://www.haskell.org/onlinereport/decls.html#sect4.3.4">Haskell Report, Section 4.3.4</ulink>)
+If no <literal>default</literal> declaration is given, then it is just as if the module
+contained the declaration <literal>default( Integer, Double, String)</literal>.
+</para></listitem>
+
+<listitem><para>
+The standard defaulting rule
 is extended thus: defaulting applies when all the unresolved constraints involve standard classes
 <emphasis>or</emphasis> <literal>IsString</literal>; and at least one is a numeric class
 <emphasis>or</emphasis> <literal>IsString</literal>.
 </para></listitem>
 </itemizedlist>
+So, for example, the expression <literal>length "foo"</literal> will give rise
+to an ambiguous use of <literal>IsString a0</literal> which, because of the above
+rules, will default to <literal>String</literal>.
 </para>
 <para>
 A small example:
@@ -5276,7 +5576,7 @@
   fromListN _ = fromList
 </programlisting>
 
-<para>The <literal>FromList</literal> class and its methods are intended to be
+<para>The <literal>IsList</literal> class and its methods are intended to be
 used in conjunction with the <option>OverloadedLists</option> extension.
 <itemizedlist>
 <listitem> <para> The type function
@@ -5308,32 +5608,32 @@
 useful for completely new data types.
 Here are several example instances:
 <programlisting>
-instance FromList [a] where
+instance IsList [a] where
   type Item [a] = a
   fromList = id
   toList = id
 
-instance (Ord a) => FromList (Set a) where
+instance (Ord a) => IsList (Set a) where
   type Item (Set a) = a
   fromList = Set.fromList
   toList = Set.toList
 
-instance (Ord k) => FromList (Map k v) where
+instance (Ord k) => IsList (Map k v) where
   type Item (Map k v) = (k,v)
   fromList = Map.fromList
   toList = Map.toList
 
-instance FromList (IntMap v) where
+instance IsList (IntMap v) where
   type Item (IntMap v) = (Int,v)
   fromList = IntMap.fromList
   toList = IntMap.toList
 
-instance FromList Text where
+instance IsList Text where
   type Item Text = Char
   fromList = Text.pack
   toList = Text.unpack
 
-instance FromList (Vector a) where
+instance IsList (Vector a) where
   type Item (Vector a) = a
   fromList  = Vector.fromList
   fromListN = Vector.fromListN
@@ -5901,28 +6201,39 @@
   data GMap (Either a b) v = GMapEither (GMap a v) (GMap b v)
   ...
 
-instance (Eq (Elem [e])) => Collects ([e]) where
+instance Eq (Elem [e]) => Collects [e] where
   type Elem [e] = e
   ...
 </programlisting>
-        The most important point about associated family instances is that the
-        type indexes corresponding to class parameters must be identical to
-        the type given in the instance head; here this is the first argument
-        of <literal>GMap</literal>, namely <literal>Either a b</literal>,
-        which coincides with the only class parameter.
-      </para>
-      <para>
-	Instances for an associated family can only appear as part of
-	instance declarations of the class in which the family was declared -
-	just as with the equations of the methods of a class.  Also in
-	correspondence to how methods are handled, declarations of associated
-	types can be omitted in class instances.  If an associated family
-	instance is omitted, the corresponding instance type is not inhabited;
+Note the following points:
+<itemizedlist>
+<listitem><para>
+        The type indexes corresponding to class parameters must have precisely the same shape
+        the type given in the instance head.  To have the same "shape" means that
+        the two types are identical modulo renaming of type variables. For example:
+<programlisting>
+instance Eq (Elem [e]) => Collects [e] where
+  -- Choose one of the following alternatives:
+  type Elem [e] = e       -- OK
+  type Elem [x] = x       -- OK
+  type Elem x   = x       -- BAD; shape of 'x' is different to '[e]'
+  type Elem [Maybe x] = x -- BAD: shape of '[Maybe x]' is different to '[e]'
+</programlisting>
+</para></listitem>
+<listitem><para>
+	An instances for an associated family can only appear as part of
+	an instance declarations of the class in which the family was declared,
+	just as with the equations of the methods of a class.
+</para></listitem>
+<listitem><para>
+     The instance for an associated type can be omitted in class instances.  In that case,
+     unless there is a default instance (see <xref linkend="assoc-decl-defs"/>),
+     the corresponding instance type is not inhabited;
 	i.e., only diverging expressions, such
 	as <literal>undefined</literal>, can assume the type.
-      </para>
-      <para>
-        Although it is unusual, there can be <emphasis>multiple</emphasis>
+</para></listitem>
+<listitem><para>
+        Although it is unusual, there (currently) can be <emphasis>multiple</emphasis>
         instances for an associated family in a single instance declaration.
         For example, this is legitimate:
 <programlisting>
@@ -5936,8 +6247,10 @@
         Since you cannot give any <emphasis>subsequent</emphasis> instances for
         <literal>(GMap Flob ...)</literal>, this facility is most useful when
         the free indexed parameter is of a kind with a finite number of alternatives
-        (unlike <literal>*</literal>).
-      </para>
+        (unlike <literal>*</literal>).  WARNING: this facility may be withdrawn in the future.
+</para></listitem>
+</itemizedlist>
+</para>
     </sect3>
 
     <sect3 id="assoc-decl-defs">
@@ -5955,22 +6268,50 @@
 instance IsBoolMap [(Int, Bool)] where
   lookupKey = lookup
 </programlisting>
-The <literal>instance</literal> keyword is optional.
-      </para>
+In an <literal>instance</literal> declaration for the class, if no explicit
+<literal>type instance</literal> declaration is given for the associated type, the default declaration
+is used instead, just as with default class methods.
+</para>
 <para>
-There can also be multiple defaults for a single type, as long as they do not
-overlap:
+Note the following points:
+<itemizedlist>
+<listitem><para>
+  The <literal>instance</literal> keyword is optional.
+</para></listitem>
+<listitem><para>
+   There can be at most one default declaration for an associated type synonym.
+</para></listitem>
+<listitem><para>
+  A default declaration is not permitted for an associated
+  <emphasis>data</emphasis> type.
+</para></listitem>
+<listitem><para>
+   The default declaration must mention only type <emphasis>variables</emphasis> on the left hand side,
+   and the right hand side must mention only type varaibels bound on the left hand side.
+   However, unlike the associated type family declaration itself,
+   the type variables of the default instance are independent of those of the parent class.
+</para></listitem>
+</itemizedlist>
+Here are some examples:
 <programlisting>
-class C a where
-  type F a b
-  type F a Int  = Bool
-  type F a Bool = Int
+  class C a where
+    type F1 a :: *
+    type instance F1 a = [a]     -- OK
+    type instance F1 a = a->a    -- BAD; only one default instance is allowed
+
+    type F2 b a                  -- OK; note the family has more type
+                                 --     variables than the class
+    type instance F2 c d = c->d  -- OK; you don't have to use 'a' in the type instance
+
+    type F3 a
+    type F3 [b] = b              -- BAD; only type variables allowed on the LHS
+
+    type F4 a
+    type F4 b = a                -- BAD; 'a' is not in scope  in the RHS
 </programlisting>
+</para>
 
-A default declaration is not permitted for an associated
-<emphasis>data</emphasis> type.
-      </para>
-    </sect3>
+</sect3>
 
     <sect3 id="scoping-class-params">
       <title>Scoping of class parameters</title>
@@ -6312,11 +6653,11 @@
 </programlisting>
 The recursive use of <literal>T</literal> forced the second argument to have kind <literal>*</literal>.
 However, just as in type inference, you can achieve polymorphic recursion by giving a
-<emphasis>complete kind signature</emphasis> for <literal>T</literal>. The way to give
-a complete kind signature for a data type is to use a GADT-style declaration with an
-explicit kind signature thus:
+<emphasis>complete kind signature</emphasis> for <literal>T</literal>. A complete
+kind signature is present when all argument kinds and the result kind are known, without
+any need for inference. For example:
 <programlisting>
-data T :: (k -> *) -> k -> * where
+data T (m :: k -> *) :: k -> * where
   MkT :: m a -> T Maybe (m a) -> T m a
 </programlisting>
 The complete user-supplied kind signature specifies the polymorphic kind for <literal>T</literal>,
@@ -6328,26 +6669,41 @@
 What exactly is considered to be a "complete user-supplied kind signature" for a type constructor?
 These are the forms:
 <itemizedlist>
-<listitem><para>
-A GADT-style data type declaration, with an explicit "<literal>::</literal>" in the header.
-For example:
+<listitem><para>For a datatype, every type variable must be annotated with a kind. In a
+GADT-style declaration, there may also be a kind signature (with a top-level
+<literal>::</literal> in the header), but the presence or absence of this annotation
+does not affect whether or not the declaration has a complete signature.
 <programlisting>
 data T1 :: (k -> *) -> k -> *       where ...   -- Yes  T1 :: forall k. (k->*) -> k -> *
 data T2 (a :: k -> *) :: k -> *     where ...   -- Yes  T2 :: forall k. (k->*) -> k -> *
 data T3 (a :: k -> *) (b :: k) :: * where ...   -- Yes  T3 :: forall k. (k->*) -> k -> *
-data T4 a (b :: k)             :: * where ...   -- YES  T4 :: forall k. * -> k -> *
+data T4 (a :: k -> *) (b :: k)      where ...   -- Yes  T4 :: forall k. (k->*) -> k -> *
 
-data T5 a b                         where ...   -- NO  kind is inferred
-data T4 (a :: k -> *) (b :: k)      where ...   -- NO  kind is inferred
-</programlisting>
-It makes no difference where you put the "<literal>::</literal>" but it must be there.
-You cannot give a complete kind signature using a Haskell-98-style data type declaration;
-you must use GADT syntax.
+data T5 a (b :: k)             :: * where ...   -- NO  kind is inferred
+data T6 a b                         where ...   -- NO  kind is inferred
+</programlisting></para>
+</listitem>
+
+<listitem><para>
+For a class, every type variable must be annotated with a kind.
 </para></listitem>
 
 <listitem><para>
+For a type synonym, every type variable and the result type must all be annotated
+with kinds.
+<programlisting>
+type S1 (a :: k) = (a :: k)    -- Yes   S1 :: forall k. k -> k
+type S2 (a :: k) = a           -- No    kind is inferred
+type S3 (a :: k) = Proxy a     -- No    kind is inferred
+</programlisting>
+Note that in <literal>S2</literal> and <literal>S3</literal>, the kind of the
+right-hand side is rather apparent, but it is still not considered to have a complete
+signature -- no inference can be done before detecting the signature.</para></listitem>
+
+<listitem><para>
 An open type or data family declaration <emphasis>always</emphasis> has a
-complete user-specified kind signature; no "<literal>::</literal>" is required:
+complete user-specified kind signature; un-annotated type variables default to
+kind <literal>*</literal>.
 <programlisting>
 data family D1 a           	-- D1 :: * -> *
 data family D2 (a :: k)    	-- D2 :: forall k. k -> *
@@ -6362,10 +6718,12 @@
 in the associated type declaration. The variable <literal>b</literal>, however,
 gets defaulted to <literal>*</literal>.
 </para></listitem>
+
+<listitem><para>
+A closed type familey has a complete signature when all of its type variables
+are annotated and a return kind (with a top-level <literal>::</literal>) is supplied.
+</para></listitem>
 </itemizedlist>
-In a complete user-specified kind signature, any un-decorated type variable to the
-left of the "<literal>::</literal>" is considered to have kind "<literal>*</literal>".
-If you want kind polymorphism, specify a kind variable.
 </para>
 
 </sect2>
@@ -6375,31 +6733,33 @@
 <para>Although all open type families are considered to have a complete
 user-specified kind signature, we can relax this condition for closed type
 families, where we have equations on which to perform kind inference. GHC will
-infer a kind for any type variable in a closed type family when that kind is
-never used in pattern-matching. If you want a kind variable to be used in
-pattern-matching, you must declare it explicitly.
-</para>
+infer kinds for the arguments and result types of a closed type family.</para>
 
-<para>
-Here are some examples (assuming <literal>-XDataKinds</literal> is enabled):
-<programlisting>
-type family Not a where      -- Not :: Bool -> Bool
-  Not False = True
-  Not True  = False
+<para>GHC supports <emphasis>kind-indexed</emphasis> type families, where the
+family matches both on the kind and type. GHC will <emphasis>not</emphasis> infer
+this behaviour without a complete user-supplied kind signature, as doing so would
+sometimes infer non-principal types.</para>
 
-type family F a where        -- ERROR: requires pattern-matching on a kind variable
-  F Int   = Bool
-  F Maybe = Char
+<para>For example:
+<programlisting>
+type family F1 a where
+  F1 True  = False
+  F1 False = True
+  F1 x     = x
+-- F1 fails to compile: kind-indexing is not inferred
 
-type family G (a :: k) where -- G :: k -> *
-  G Int   = Bool
-  G Maybe = Char
+type family F2 (a :: k) where
+  F2 True  = False
+  F2 False = True
+  F2 x     = x
+-- F2 fails to compile: no complete signature
 
-type family SafeHead where   -- SafeHead :: [k] -> Maybe k
-  SafeHead '[] = Nothing     -- note that k is not required for pattern-matching
-  SafeHead (h ': t) = Just h
-</programlisting>
-</para>
+type family F3 (a :: k) :: k where
+  F3 True  = False
+  F3 False = True
+  F3 x     = x
+-- OK
+</programlisting></para>
 
 </sect2>
 
@@ -6569,9 +6929,9 @@
 </sect2>
 
 <sect2 id="promoted-lists-and-tuples">
-<title>Promoted lists and tuples types</title>
+<title>Promoted list and tuple types</title>
 <para>
-Haskell's list and tuple types are natively promoted to kinds, and enjoy the
+With <option>-XDataKinds</option>, Haskell's list and tuple types are natively promoted to kinds, and enjoy the
 same convenient syntax at the type level, albeit prefixed with a quote:
 <programlisting>
 data HList :: [*] -> * where
@@ -6580,8 +6940,23 @@
 
 data Tuple :: (*,*) -> * where
   Tuple :: a -> b -> Tuple '(a,b)
+
+foo0 :: HList '[]
+foo0 = HNil
+
+foo1 :: HList '[Int]
+foo1 = HCons (3::Int) HNil
+
+foo2 :: HList [Int, Bool]
+foo2 = ...
 </programlisting>
-Note that this requires <option>-XTypeOperators</option>.
+(Note: the declaration for <literal>HCons</literal> also requires <option>-XTypeOperators</option>
+because of infix type operator <literal>(:')</literal>.)
+For type-level lists of <emphasis>two or more elements</emphasis>,
+such as the signature of <literal>foo2</literal> above, the quote may be omitted because the meaning is
+unambiguous. But for lists of one or zero elements (as in <literal>foo0</literal>
+and <literal>foo1</literal>), the quote is required, because the types <literal>[]</literal>
+and <literal>[Int]</literal> have existing meanings in Haskell.
 </para>
 </sect2>
 
@@ -6871,7 +7246,7 @@
 			type <literal>(Show a, Ord a)</literal> is of kind <literal>Constraint</literal>.
 		</listitem>
 		<listitem>
-			Anything whose form is not yet know, but the user has declared to have kind <literal>Constraint</literal>
+			Anything whose form is not yet known, but the user has declared to have kind <literal>Constraint</literal>
 			(for which they need to import it from <literal>GHC.Exts</literal>).  So for example
 			<literal>type Foo (f :: * -> Constraint) = forall b. f b => b -> b</literal> is allowed, as well as
 			examples involving type families:
@@ -6974,13 +7349,13 @@
 
 <para>
 Each user-written type signature is subjected to an
-<emphasis>ambiguity check</emphasis>.  
+<emphasis>ambiguity check</emphasis>.
 The ambiguity check rejects functions that can never be called; for example:
 <programlisting>
    f :: C a => Int
 </programlisting>
 The idea is there can be no legal calls to <literal>f</literal> because every call will
-give rise to an ambiguous constraint.  
+give rise to an ambiguous constraint.
 Indeed, the <emphasis>only</emphasis> purpose of the
 ambiguity check is to report functions that cannot possibly be called.
 We could soundly omit the
@@ -6992,7 +7367,7 @@
 Ambiguity can be subtle.  Consider this example which uses functional dependencies:
 <programlisting>
    class D a b | a -> b where ..
-   h :: D Int b => Int 
+   h :: D Int b => Int
 </programlisting>
 The <literal>Int</literal> may well fix <literal>b</literal> at the call site, so that signature should
 not be rejected.  Moreover, the dependencies might be hidden. Consider
@@ -7007,12 +7382,12 @@
    ...(h [True])...
 </programlisting>
 That gives rise to a <literal>(X [Bool] beta)</literal> constraint, and using the
-instance means we need <literal>(D Bool beta)</literal> and that 
+instance means we need <literal>(D Bool beta)</literal> and that
 fixes <literal>beta</literal> via <literal>D</literal>'s
 fundep!
 </para>
 <para>
-Behind all these special cases there is a simple guiding principle. 
+Behind all these special cases there is a simple guiding principle.
 Consider
 <programlisting>
   f :: <replaceable>type</replaceable>
@@ -7022,7 +7397,7 @@
   g = f
 </programlisting>
 You would think that the definition of <literal>g</literal> would surely typecheck!
-After all <literal>f</literal> has exactly the same type, and <literal>g=f</literal>. 
+After all <literal>f</literal> has exactly the same type, and <literal>g=f</literal>.
 But in fact <literal>f</literal>'s type
 is instantiated and the instantiated constraints are solved against
 the constraints bound by <literal>g</literal>'s signature.  So, in the case an ambiguous type, solving will fail.
@@ -7076,7 +7451,7 @@
 on type signatures. For type type
 <literal>forall tv1..tvn (c1, ...,cn) => type</literal>
 GHC used to require (a) that each universally quantified type variable
-<literal>tvi</literal> must be "reachable" from <literal>type</literal>, 
+<literal>tvi</literal> must be "reachable" from <literal>type</literal>,
 and (b) that every constraint <literal>ci</literal> mentions at least one of the
 universally quantified type variables <literal>tvi</literal>.
 These ad-hoc restrictions are completely subsumed by the new ambiguity check.
@@ -7308,6 +7683,57 @@
 <literal>14</literal>.
 </para>
 </sect3>
+
+<sect3 id="special-implicit-params">
+<title>Special implicit parameters</title>
+<para>
+GHC treats implicit parameters of type <literal>GHC.Stack.CallStack</literal>
+specially, by resolving them to the current location in the program. Consider:
+<programlisting>
+  f :: String
+  f = show (?loc :: CallStack)
+</programlisting>
+GHC will automatically resolve <literal>?loc</literal> to its source
+location. If another implicit parameter with type <literal>CallStack</literal> is
+in scope, GHC will append the two locations, creating an explicit call-stack. For example:
+<programlisting>
+  f :: (?stk :: CallStack) => String
+  f = show (?stk :: CallStack)
+</programlisting>
+will produce the location of <literal>?stk</literal>, followed by
+<literal>f</literal>'s call-site. Note that the name of the implicit parameter does not
+matter (we used <literal>?loc</literal> above), GHC will solve any implicit parameter
+with the right type. The name does, however, matter when pushing new locations onto
+existing stacks. Consider:
+<programlisting>
+  f :: (?stk :: CallStack) => String
+  f = show (?loc :: CallStack)
+</programlisting>
+When we call <literal>f</literal>, the stack will include the use of <literal>?loc</literal>,
+but not the call to <literal>f</literal>; in this case the names must match.
+</para>
+<para>
+<literal>CallStack</literal> is kept abstract, but
+GHC provides a function
+<programlisting>
+  getCallStack :: CallStack -> [(String, SrcLoc)]
+</programlisting>
+to access the individual call-sites in the stack. The <literal>String</literal>
+is the name of the function that was called, and the <literal>SrcLoc</literal>
+provides the package, module, and file name, as well as the line and column
+numbers. The stack will never be empty, as the first call-site
+will be the location at which the implicit parameter was used. GHC will also
+never infer <literal>?loc :: CallStack</literal> as a type constraint, which
+means that functions must explicitly ask to be told about their call-sites.
+</para>
+<para>
+A potential "gotcha" when using implicit <literal>CallStack</literal>s is that
+the <literal>:type</literal> command in GHCi will not report the
+<literal>?loc :: CallStack</literal> constraint, as the typechecker will
+immediately solve it. Use <literal>:info</literal> instead to print the
+unsolved type.
+</para>
+</sect3>
 </sect2>
 
 <sect2 id="kinding">
@@ -7457,7 +7883,7 @@
                           bind   :: forall a b. m a -> (a -> m b) -> m b
                         }
 
-newtype Swizzle = MkSwizzle (Ord a => [a] -> [a])
+newtype Swizzle = MkSwizzle (forall a. Ord a => [a] -> [a])
 </programlisting>
 
 </para>
@@ -7473,22 +7899,22 @@
 MkMonad :: forall m. (forall a. a -> m a)
                   -> (forall a b. m a -> (a -> m b) -> m b)
                   -> MonadT m
-MkSwizzle :: (Ord a => [a] -> [a]) -> Swizzle
+MkSwizzle :: (forall a. Ord a => [a] -> [a]) -> Swizzle
 </programlisting>
 
 </para>
 
 <para>
-Notice that you don't need to use a <literal>forall</literal> if there's an
-explicit context.  For example in the first argument of the
-constructor <function>MkSwizzle</function>, an implicit "<literal>forall a.</literal>" is
-prefixed to the argument type.  The implicit <literal>forall</literal>
-quantifies all type variables that are not already in scope, and are
-mentioned in the type quantified over. (Arguably, it would be better
-to <emphasis>require</emphasis> explicit quantification on constructor arguments
-where that is what is wanted.
-See <ulink url="http://ghc.haskell.org/trac/ghc/ticket/4426">Trac #4426</ulink>.)
+In earlier versions of GHC, it was possible to omit the <literal>forall</literal>
+in the type of the constructor if there was an explicit context. For example:
 
+<programlisting>
+newtype Swizzle' = MkSwizzle' (Ord a => [a] -> [a])
+</programlisting>
+
+As of GHC 7.10, this is deprecated. The <literal>-fwarn-context-quantification</literal>
+flag detects this situation and issues a warning. In GHC 7.12, declarations
+such as <literal>MkSwizzle'</literal> will cause an out-of-scope error.
 </para>
 
 <para>
@@ -7998,7 +8424,7 @@
 of the Haskell Report)
 can be completely switched off by
 <option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, the monomorphism
-restriction is switched off by default in GHCi.
+restriction is switched off by default in GHCi's interactive options (see <xref linkend="ghci-interactive-options"/>).
 </para>
 </sect3>
 
@@ -8071,12 +8497,30 @@
 <para>
 An ML-style language usually generalises the type of any let-bound or where-bound variable,
 so that it is as polymorphic as possible.
-With the flag <option>-XMonoLocalBinds</option> GHC implements a slightly more conservative policy:
-<emphasis>it generalises only "closed" bindings</emphasis>.
-A binding is considered "closed" if either
+With the flag <option>-XMonoLocalBinds</option> GHC implements a slightly more conservative policy,
+using the following rules:
 <itemizedlist>
-<listitem><para>It is one of the top-level bindings of a module, or </para></listitem>
-<listitem><para>Its free variables are all themselves closed</para></listitem>
+  <listitem><para>
+  A variable is <emphasis>closed</emphasis> if and only if
+    <itemizedlist>
+    <listitem><para> the variable is let-bound</para></listitem>
+    <listitem><para> one of the following holds:
+          <itemizedlist>
+          <listitem><para>the variable has an explicit type signature that has no free type variables, or</para></listitem>
+          <listitem><para>its binding group is fully generalised (see next bullet) </para></listitem>
+         </itemizedlist>
+    </para></listitem>
+    </itemizedlist>
+  </para></listitem>
+
+  <listitem><para>
+  A binding group is <emphasis>fully generalised</emphasis> if and only if
+    <itemizedlist>
+    <listitem><para>each of its free variables is either imported or closed, and</para></listitem>
+    <listitem><para>the binding is not affected by the monomorphism restriction
+        (<ulink url="http://www.haskell.org/onlinereport/decls.html#sect4.5.5">Haskell Report, Section 4.5.5</ulink>)</para></listitem>
+    </itemizedlist>
+  </para></listitem>
 </itemizedlist>
 For example, consider
 <programlisting>
@@ -8085,15 +8529,18 @@
           k z = z+x
       in  h x + k x
 </programlisting>
-Here <literal>f</literal> and <literal>g</literal> are closed because they are bound at top level.
-Also <literal>h</literal> is closed because its only free variable <literal>f</literal> is closed.
-But <literal>k</literal> is not closed because it mentions <literal>x</literal> which is locally bound.
-Another way to think of it is this: all closed bindings <literal>could</literal> be defined at top level.
-(In the example, we could move <literal>h</literal> to top level.)
-</para><para>
-All of this applies only to bindings that lack an explicit type signature, so that GHC has to
-infer its type.  If you supply a type signature, then that fixes type of the binding, end of story.
-</para><para>
+Here <literal>f</literal> is generalised because it has no free variables; and its binding group
+is unaffected by the monomorphism restriction; and hence <literal>f</literal> is closed.
+The same reasoning applies to <literal>g</literal>, except that it has one closed free variable, namely <literal>f</literal>.
+Similarly <literal>h</literal> is closed, <emphasis>even though it is not bound at top level</emphasis>,
+because its only free variable <literal>f</literal> is closed.
+But <literal>k</literal> is not closed, because it mentions <literal>x</literal> which is not closed (because it is not let-bound).
+</para>
+<para>
+Notice that a top-level binding that is affected by the monomorphism restriction is not closed, and hence may
+in turn prevent generalisation of bindings that mention it.
+</para>
+<para>
 The rationale for this more conservative strategy is given in
 <ulink url="http://research.microsoft.com/~simonpj/papers/constraints/index.htm">the papers</ulink> "Let should not be generalised" and "Modular type inference with local assumptions", and
 a related <ulink url="http://ghc.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7">blog post</ulink>.
@@ -8110,31 +8557,37 @@
 <sect1 id="typed-holes">
 <title>Typed Holes</title>
 
-<para>Typed hole support is enabled with the option
-<option>-fwarn-typed-holes</option>, which is enabled by default.</para>
-
 <para>
-This option allows special placeholders, written with a leading underscore (e.g. "<literal>_</literal>",
-"<literal>_foo</literal>", "<literal>_bar</literal>"), to be used as an expression.
-During compilation these holes will generate an error message describing what type is expected there,
-information about the origin of any free type variables, and a list of local bindings
-that might help fill the hole with actual code.
+Typed holes are a feature of GHC that allows special placeholders written with
+a leading underscore (e.g., "<literal>_</literal>", "<literal>_foo</literal>",
+"<literal>_bar</literal>"), to be used as expressions. During compilation these
+holes will generate an error message that describes which type is expected at
+the hole's location, information about the origin of any free type variables,
+and a list of local bindings that might help fill the hole with actual code.
+Typed holes are always enabled in GHC.
 </para>
 
 <para>
-The goal of the typed holes warning is not to change the type system, but to help with writing Haskell
-code. Typed holes can be used to obtain extra information from the type checker, which might otherwise be hard
-to get.
-Normally, using GHCi, users can inspect the (inferred) type signatures of all top-level bindings.
-However, this method is less convenient with terms which are not defined on top-level or
-inside complex expressions. Holes allow to check the type of the term you're about to write.
+The goal of typed holes is to help with writing Haskell code rather than to
+change the type system. Typed holes can be used to obtain extra information
+from the type checker, which might otherwise be hard to get. Normally, using
+GHCi, users can inspect the (inferred) type signatures of all top-level
+bindings. However, this method is less convenient with terms that are not
+defined on top-level or inside complex expressions. Holes allow the user to
+check the type of the term they are about to write.
 </para>
 
 <para>
-Holes work together well with <link linkend="defer-type-errors">deferring type errors to runtime</link>:
-with <literal>-fdefer-type-errors</literal>, the error from a hole is also deferred, effctively making the hole
-typecheck just like <literal>undefined</literal>, but with the added benefit that it will show its warning message
-if it gets evaluated. This way, other parts of the code can still be executed and tested.
+To run and test a piece of code containing holes, use the
+<literal>-fdefer-typed-holes</literal> flag. This flag defers errors
+produced by typed holes and converts them into warnings. The result is that
+typed hole errors are converted into warnings (controlled by
+<literal>-fwarn-typed-holes</literal>). The result is that a hole will behave
+like <literal>undefined</literal>, but with the added benefits that it shows a
+warning at compile time and will show another warning message if it gets
+evaluated. This behaviour follows that of the
+<literal>-fdefer-type-errors</literal> option, which implies
+<literal>-fdefer-typed-holes</literal>. See <xref linkend="defer-type-errors"/>.
 </para>
 
 <para>
@@ -8211,6 +8664,293 @@
 </para>
 
 </sect1>
+<!-- ==================== Partial Type Signatures =================  -->
+
+<sect1 id="partial-type-signatures">
+<title>Partial Type Signatures</title>
+
+<para>
+A partial type signature is a type signature containing special placeholders
+written with a leading underscore (e.g., "<literal>_</literal>",
+"<literal>_foo</literal>", "<literal>_bar</literal>") called
+<emphasis>wildcards</emphasis>. Partial type signatures are to type signatures
+what <xref linkend="typed-holes"/> are to expressions. During compilation these
+wildcards or holes will generate an error message that describes which type
+was inferred at the hole's location, and information about the origin of any
+free type variables. GHC reports such error messages by default.</para>
+
+<para>
+Unlike <xref linkend="typed-holes"/>, which make the program incomplete and
+will generate errors when they are evaluated, this needn't be the case for
+holes in type signatures. The type checker is capable (in most cases) of
+type-checking a binding with or without a type signature. A partial type
+signature bridges the gap between the two extremes, the programmer can choose
+which parts of a type to annotate and which to leave over to the type-checker
+to infer.
+</para>
+
+<para>
+By default, the type-checker will report an error message for each hole in a
+partial type signature, informing the programmer of the inferred type. When
+the <option>-XPartialTypeSignatures</option> flag is enabled, the type-checker
+will accept the inferred type for each hole, generating warnings instead of
+errors. Additionally, these warnings can be silenced with the
+<option>-fno-warn-partial-type-signatures</option> flag.
+</para>
+
+<sect2 id="pts-syntax">
+<title>Syntax</title>
+
+<para>
+A (partial) type signature has the following form: <literal>forall a b .. .
+(C1, C2, ..) => tau</literal>. It consists of three parts:
+</para>
+
+<itemizedlist>
+    <listitem>The type variables: <literal>a b ..</literal></listitem>
+    <listitem>The constraints: <literal>(C1, C2, ..)</literal></listitem>
+    <listitem>The (mono)type: <literal>tau</literal></listitem>
+</itemizedlist>
+
+<para>
+We distinguish three kinds of wildcards.
+</para>
+
+<sect3 id="type-wildcards">
+<title>Type Wildcards</title>
+<para>
+Wildcards occurring within the monotype (tau) part of the type signature are
+<emphasis>type wildcards</emphasis> ("type" is often omitted as this is the
+default kind of wildcard). Type wildcards can be instantiated to any monotype
+like <literal>Bool</literal> or <literal>Maybe [Bool]</literal>, including
+functions and higher-kinded types like <literal>(Int -> Bool)</literal> or
+<literal>Maybe</literal>.
+</para>
+<programlisting>
+not' :: Bool -> _
+not' x = not x
+-- Inferred: Bool -> Bool
+
+maybools :: _
+maybools = Just [True]
+-- Inferred: Maybe [Bool]
+
+just1 :: _ Int
+just1 = Just 1
+-- Inferred: Maybe Int
+
+filterInt :: _ -> _ -> [Int]
+filterInt = filter -- has type forall a. (a -> Bool) -> [a] -> [a]
+-- Inferred: (Int -> Bool) -> [Int] -> [Int]
+</programlisting>
+
+<para>
+For instance, the first wildcard in the type signature <literal>not'</literal>
+would produce the following error message:
+</para>
+<programlisting>
+Test.hs:4:17:
+    Found hole &lsquo;_&rsquo; with type: Bool
+    To use the inferred type, enable PartialTypeSignatures
+    In the type signature for &lsquo;not'&rsquo;: Bool -> _
+</programlisting>
+
+<para>
+When a wildcard is not instantiated to a monotype, it will be generalised
+over, i.e. replaced by a fresh type variable (of which the name will often
+start with <literal>w_</literal>), e.g.
+</para>
+<programlisting>
+foo :: _ -> _
+foo x = x
+-- Inferred: forall w_. w_ -> w_
+
+filter' :: _
+filter' = filter -- has type forall a. (a -> Bool) -> [a] -> [a]
+-- Inferred: (a -> Bool) -> [a] -> [a]
+</programlisting>
+</sect3>
+
+<sect3 id="named-wildcards">
+<title>Named Wildcards</title>
+<para>
+Type wildcards can also be named by giving the underscore an identifier as
+suffix, i.e. <literal>_a</literal>. These are called <emphasis>named
+wildcards</emphasis>. All occurrences of the same named wildcard within one
+type signature will unify to the same type. For example:
+</para>
+<programlisting>
+f :: _x -> _x
+f ('c', y) = ('d', error "Urk")
+-- Inferred: forall t. (Char, t) -> (Char, t)
+</programlisting>
+
+<para>
+The named wildcard forces the argument and result types to be the same.
+Lacking a signature, GHC would have inferred <literal>forall a b. (Char, a) ->
+(Char, b)</literal>. A named wildcard can be mentioned in constraints,
+provided it also occurs in the monotype part of the type signature to make
+sure that it unifies with something:
+</para>
+
+<programlisting>
+somethingShowable :: Show _x => _x -> _
+somethingShowable x = show x
+-- Inferred type: Show w_x => w_x -> String
+
+somethingShowable' :: Show _x => _x -> _
+somethingShowable' x = show (not x)
+-- Inferred type: Bool -> String
+</programlisting>
+
+<para>
+Besides an extra-constraints wildcard (see <xref
+linkend="extra-constraints-wildcard"/>), only named wildcards can occur in the
+constraints, e.g. the <literal>_x</literal> in <literal>Show _x</literal>.
+</para>
+
+<para>
+Named wildcards <emphasis>should not be confused with type
+variables</emphasis>. Even though syntactically similar, named wildcards can
+unify with monotypes as well as be generalised over (and behave as type
+variables).</para>
+
+<para>
+In the first example above, <literal>_x</literal> is generalised over (and is
+effectively replaced by a fresh type variable <literal>w_x</literal>). In the
+second example, <literal>_x</literal> is unified with the
+<literal>Bool</literal> type, and as <literal>Bool</literal> implements the
+<literal>Show</literal> type class, the constraint <literal>Show
+Bool</literal> can be simplified away.
+</para>
+
+<para>
+By default, GHC (as the Haskell 2010 standard prescribes) parses identifiers
+starting with an underscore in a type as type variables. To treat them as
+named wildcards, the <option>-XNamedWildCards</option> flag should be enabled.
+The example below demonstrated the effect.
+</para>
+
+<programlisting>
+foo :: _a -> _a
+foo _ = False
+</programlisting>
+
+<para>
+Compiling this program without enabling <option>-XNamedWildCards</option>
+produces the following error message complaining about the type variable
+<literal>_a</literal> no matching the actual type <literal>Bool</literal>.
+</para>
+
+<programlisting>
+Test.hs:5:9:
+    Couldn't match expected type &lsquo;_a&rsquo; with actual type &lsquo;Bool&rsquo;
+      &lsquo;_a&rsquo; is a rigid type variable bound by
+           the type signature for foo :: _a -> _a at Test.hs:4:8
+    Relevant bindings include foo :: _a -> _a (bound at Test.hs:4:1)
+    In the expression: False
+    In an equation for &lsquo;foo&rsquo;: foo _ = False
+</programlisting>
+
+<para>
+Compiling this program with <option>-XNamedWildCards</option> enabled produces
+the following error message reporting the inferred type of the named wildcard
+<literal>_a</literal>.
+</para>
+
+<programlisting>
+Test.hs:4:8: Warning:
+    Found hole &lsquo;_a&rsquo; with type: Bool
+    In the type signature for &lsquo;foo&rsquo;: _a -> _a
+</programlisting>
+</sect3>
+
+<sect3 id="extra-constraints-wildcard">
+<title>Extra-Constraints Wildcard</title>
+
+<para>
+The third kind of wildcard is the <emphasis>extra-constraints
+wildcard</emphasis>. The presence of an extra-constraints wildcard indicates
+that an arbitrary number of extra constraints may be inferred during type
+checking and will be added to the type signature. In the example below, the
+extra-constraints wildcard is used to infer three extra constraints.
+</para>
+
+<programlisting>
+arbitCs :: _ => a -> String
+arbitCs x = show (succ x) ++ show (x == x)
+-- Inferred:
+--   forall a. (Enum a, Eq a, Show a) => a -> String
+-- Error:
+Test.hs:5:12:
+    Found hole &lsquo;_&rsquo; with inferred constraints: (Enum a, Eq a, Show a)
+    To use the inferred type, enable PartialTypeSignatures
+    In the type signature for &lsquo;arbitCs&rsquo;: _ => a -> String
+</programlisting>
+
+<para>
+An extra-constraints wildcard shouldn't prevent the programmer from already
+listing the constraints he knows or wants to annotate, e.g.
+</para>
+
+<programlisting>
+-- Also a correct partial type signature:
+arbitCs' :: (Enum a, _) => a -> String
+arbitCs' x = arbitCs x
+-- Inferred:
+--   forall a. (Enum a, Show a, Eq a) => a -> String
+-- Error:
+Test.hs:9:22:
+    Found hole &lsquo;_&rsquo; with inferred constraints: (Eq a, Show a)
+    To use the inferred type, enable PartialTypeSignatures
+    In the type signature for &lsquo;arbitCs'&rsquo;: (Enum a, _) => a -> String
+</programlisting>
+
+<para>
+An extra-constraints wildcard can also lead to zero extra constraints to be
+inferred, e.g.
+</para>
+
+<programlisting>
+noCs :: _ => String
+noCs = "noCs"
+-- Inferred: String
+-- Error:
+Test.hs:13:9:
+    Found hole &lsquo;_&rsquo; with inferred constraints: ()
+    To use the inferred type, enable PartialTypeSignatures
+    In the type signature for &lsquo;noCs&rsquo;: _ => String
+</programlisting>
+
+<para>
+As a single extra-constraints wildcard is enough to infer any number of
+constraints, only one is allowed in a type signature and it should come last
+in the list of constraints.
+</para>
+
+<para>
+Extra-constraints wildcards cannot be named.
+</para>
+
+</sect3>
+</sect2>
+
+<sect2 id="pts-where">
+<title>Where can they occur?</title>
+
+<para>
+Partial type signatures are allowed for bindings, pattern and expression signatures.
+In all other contexts, e.g. type class or type family declarations, they are disallowed.
+In the following example a wildcard is used in each of the three possible contexts.
+</para>
+<programlisting>
+{-# LANGUAGE ScopedTypeVariables #-}
+foo :: _
+foo (x :: _) = (x :: _)
+-- Inferred: forall w_. w_ -> w_
+</programlisting>
+</sect2>
+</sect1>
 <!-- ==================== Deferring type errors =================  -->
 
 <sect1 id="defer-type-errors">
@@ -8245,6 +8985,15 @@
     warnings, but will not prevent compilation.
   </para>
   <para>
+    This flag implies the <literal>-fdefer-typed-holes</literal> flag,
+    which enables this behaviour for <link linkend="typed-holes">typed holes
+    </link>. Should you so wish, it is possible to enable
+    <literal>-fdefer-type-errors</literal> without enabling
+    <literal>-fdefer-typed-holes</literal>, by explicitly specifying
+    <literal>-fno-defer-typed-holes</literal> on the commandline after the
+    <literal>-fdefer-type-errors</literal> flag.
+  </para>
+  <para>
     At runtime, whenever a term containing a type error would need to be
     evaluated, the error is converted into a runtime exception.
     Note that type errors are deferred as much as possible during runtime, but
@@ -8364,11 +9113,13 @@
 		    have type <literal>Q Pat</literal></para></listitem>
 		    <listitem><para> a type; the spliced expression must
 		    have type <literal>Q Type</literal></para></listitem>
-		    <listitem><para> a list of declarations; the spliced expression
+		    <listitem><para> a list of declarations at top level; the spliced expression
                     must have type <literal>Q [Dec]</literal></para></listitem>
 		    </itemizedlist>
             Inside a splice you can only call functions defined in imported modules,
-	    not functions defined elsewhere in the same module.</para></listitem>
+	    not functions defined elsewhere in the same module. Note that
+	    declaration splices are not allowed anywhere except at top level
+	      (outside any other declarations).</para></listitem>
 
 	      <listitem><para>
 		  A expression quotation is written in Oxford brackets, thus:
@@ -8469,28 +9220,57 @@
 </programlisting>
             This abbreviation makes top-level declaration slices quieter and less intimidating.
 	    </para></listitem>
-	    
+
 	    <listitem>
 	      <para>
-		Binders are lexically scoped. For example, consider the
-		following code, where a value <literal>g</literal> of type
-		<literal>Bool -> Q Pat</literal> is in scope, having been
-		imported from another module
+		Outermost pattern splices may bind variables. By "outermost" here, we refer to
+		a pattern splice that occurs outside of any quotation brackets. For example,
+
 <programlisting>
-y :: Int
-y = 7
+mkPat :: Bool -> Q Pat
+mkPat True  = [p| (x, y) |]
+mkPat False = [p| (y, x) |]
 
-f :: Int -> Int -> Int
-f n = \ $(g True) -> y+n
+-- in another module:
+foo :: (Char, String) -> String
+foo $(mkPat True) = x : y
+
+bar :: (String, Char) -> String
+bar $(mkPat False) = x : y
 </programlisting>
-                The <literal>y</literal> in the right-hand side of
-                <literal>f</literal> refers to the top-level <literal>y =
-                7</literal>, even if the pattern splice <literal>$(g
-                n)</literal> also generates a binder <literal>y</literal>.
 	      </para>
+	    </listitem>
+
 
+	    <listitem>
 	      <para>
-		Note that a pattern quasiquoter <emphasis>may</emphasis>
+		Nested pattern splices do <emphasis>not</emphasis> bind variables.
+		By "nested" here, we refer to a pattern splice occurring within a
+		quotation bracket. Continuing the example from the last bullet:
+
+<programlisting>
+baz :: Bool -> Q Exp
+baz b = [| quux $(mkPat b) = x + y |]
+</programlisting>
+
+                would fail with <literal>x</literal> and <literal>y</literal>
+		being out of scope.
+	      </para>
+
+	      <para>
+		The difference in treatment of outermost and nested pattern splices is
+		because outermost splices are run at compile time. GHC can then use
+		the result of running the splice when analyzing the expressions within
+		the pattern's scope. Nested splices, on the other hand, are <emphasis>not</emphasis>
+		run at compile time; they are run when the bracket is spliced in, sometime later.
+		Since nested pattern splices may refer to local variables, there is no way for GHC
+		to know, at splice compile time, what variables are bound, so it binds none.
+	      </para>
+	    </listitem>
+
+	    <listitem>
+	      <para>
+		A pattern quasiquoter <emphasis>may</emphasis>
 		generate binders that scope over the right-hand side of a
 		definition because these binders are in scope lexically. For
 		example, given a quasiquoter <literal>haskell</literal> that
@@ -8509,21 +9289,29 @@
 	      </para>
 	    </listitem>
 	    <listitem>
-	      <para>
-		The type environment seen by <literal>reify</literal> includes
-		all the top-level declaration up to the end of the immediately
-		preceding <emphasis>declaration group</emphasis>, but no more.
+              <para>
+		Top-level declaration splices break up a source file into
+		<emphasis>delcaration groups</emphasis>. A
+		<emphasis>declaration group</emphasis> is the group of
+		declarations created by a top-level declaration splice, plus
+		those following it, down to but not including the next
+		top-level declaration splice. The first declaration group in a
+		module includes all top-level definitions down to but not
+		including the first top-level declaration splice.
 	      </para>
 
 	      <para>
-		A <emphasis>declaration group</emphasis> is the group of
-		declarations created by a top-level declaration splice, plus
-		those following it, down to but not including the next top-level
-		declaration splice. The first declaration group in a module
-		includes all top-level definitions down to but not including the
-		first top-level declaration splice.
+		Each declaration group is mutually recursive only within
+		the group. Declaration groups can refer to definitions within
+		previous groups, but not later ones.
 	      </para>
 
+	      <para>
+		Accordingly, the type environment seen by
+		<literal>reify</literal> includes all the top-level
+		declarations up to the end of the immediately preceding
+		declaration group, but no more.
+	      </para>
 
 	      <para>
 		Concretely, consider the following code
@@ -8541,6 +9329,11 @@
               <orderedlist>
 		<listitem>
 		  <para>
+		    The body of <literal>h</literal> would be unable to refer
+		    to the function <literal>w</literal>.
+		  </para>
+
+		  <para>
 		    A <literal>reify</literal> inside the splice <literal>$(th1
 		    ..)</literal> would see the definition of
 		    <literal>f</literal>.
@@ -8610,9 +9403,6 @@
    </para></listitem>
 
     <listitem><para>
-	    The flag <literal>-ddump-splices</literal> shows the expansion of all top-level splices as they happen.
-   </para></listitem>
-    <listitem><para>
 	    If you are building GHC from source, you need at least a stage-2 bootstrap compiler to
 	      run Template Haskell.  A stage-1 compiler will reject the TH constructs.  Reason: TH
 	      compiles and runs a program, and then looks at the result.  So it's important that
@@ -8627,6 +9417,45 @@
 </para>
 </sect2>
 
+<sect2 id="th-view-gen-code"> <title> Viewing Template Haskell generated code </title>
+  <para>
+    The flag <literal>-ddump-splices</literal> shows the expansion of all top-level declaration splices, both typed and untyped, as they happen.
+    As with all dump flags, the default is for this output to be sent to stdout.
+    For a non-trivial program, you may be interested in combining this with the <literal>-ddump-to-file flag</literal> (see <xref linkend="dumping-output"/>.
+    For each file using Template Haskell, this will show the output in a <literal>.dump-splices</literal> file.
+  </para>
+
+  <para>
+    The flag <literal>-dth-dec-file</literal> shows the expansions of all top-level TH declaration splices, both typed and untyped, in the file <literal>M.th.hs</literal> where M is the name of the module being compiled.
+    Note that other types of splices (expressions, types, and patterns) are not shown.
+    Application developers can check this into their repository so that they can grep for identifiers that were defined in Template Haskell.
+    This is similar to using <option>-ddump-to-file</option> with <option>-ddump-splices</option> but it always generates a file instead of being coupled to <option>-ddump-to-file</option>. The format is also different: it does not show code from the original file, instead it only shows generated code and has a comment for the splice location of the original file.
+  </para>
+
+  <para>
+    Below is a sample output of <literal>-ddump-splices</literal>
+  </para>
+
+<programlisting>
+TH_pragma.hs:(6,4)-(8,26): Splicing declarations
+  [d| foo :: Int -> Int
+      foo x = x + 1 |]
+======>
+  foo :: Int -> Int
+  foo x = (x + 1)
+</programlisting>
+
+  <para>
+  Below is the output of the same sample using <literal>-dth-dec-file</literal>
+  </para>
+
+<programlisting>
+-- TH_pragma.hs:(6,4)-(8,26): Splicing declarations
+foo :: Int -> Int
+foo x = (x + 1)
+</programlisting>
+</sect2>
+
 <sect2 id="th-example">  <title> A Template Haskell Worked Example </title>
 <para>To help you get over the confidence barrier, try out this skeletal worked example.
   First cut and paste the two modules below into "Main.hs" and "Printf.hs":</para>
@@ -8736,7 +9565,7 @@
 <para>Quasi-quotation allows patterns and expressions to be written using
 programmer-defined concrete syntax; the motivation behind the extension and
 several examples are documented in
-"<ulink url="http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/">Why It's
+"<ulink url="http://www.cs.tufts.edu/comp/150FP/archive/geoff-mainland/quasiquoting.pdf">Why It's
 Nice to be Quoted: Quasiquoting for Haskell</ulink>" (Proc Haskell Workshop
 2007). The example below shows how to write a quasiquoter for a simple
 expression language.</para>
@@ -8748,8 +9577,8 @@
 <literal>[<replaceable>quoter</replaceable>| <replaceable>string</replaceable> |]</literal>.
 <itemizedlist>
 <listitem><para>
-The <replaceable>quoter</replaceable> must be the (unqualified) name of an imported
-quoter; it cannot be an arbitrary expression.
+The <replaceable>quoter</replaceable> must be the name of an imported quoter,
+either qualified or unqualified; it cannot be an arbitrary expression.
 </para></listitem>
 <listitem><para>
 The <replaceable>quoter</replaceable> cannot be "<literal>e</literal>",
@@ -8942,7 +9771,7 @@
 
 <listitem>
 <para>
-&ldquo;<ulink url="http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf">Programming with Arrows</ulink>&rdquo;,
+&ldquo;<ulink url="http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf">Programming with Arrows</ulink>&rdquo;,
 John Hughes, in <citetitle>5th International Summer School on
 Advanced Functional Programming</citetitle>,
 <citetitle>Lecture Notes in Computer Science</citetitle> vol. 3622,
@@ -9710,6 +10539,129 @@
 
 </sect1>
 
+<!-- =============================== STATIC POINTERS ===========================  -->
+
+<sect1 id="static-pointers">
+<title>Static pointers
+<indexterm><primary>Static pointers</primary></indexterm>
+</title>
+
+<para>
+The language extension <literal>-XStaticPointers</literal> adds a new
+syntactic form <literal>static <replaceable>e</replaceable></literal>,
+which stands for a reference to the closed expression
+<replaceable>e</replaceable>. This reference is stable and portable,
+in the sense that it remains valid across different processes on
+possibly different machines. Thus, a process can create a reference
+and send it to another process that can resolve it to
+<replaceable>e</replaceable>.
+</para>
+<para>
+With this extension turned on, <literal>static</literal> is no longer
+a valid identifier.
+</para>
+<para>
+Static pointers were first proposed in the paper <ulink
+url="http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf">
+Towards Haskell in the cloud</ulink>, Jeff Epstein, Andrew P. Black and Simon
+Peyton-Jones, Proceedings of the 4th ACM Symposium on Haskell, pp.
+118-129, ACM, 2011.
+</para>
+
+<sect2 id="using-static-pointers">
+<title>Using static pointers</title>
+
+<para>
+Each reference is given a key which can be used to locate it at runtime with
+<ulink url="&libraryBaseLocation;/GHC.StaticPtr.html#v%3AunsafeLookupStaticPtr"><literal>unsafeLookupStaticPtr</literal></ulink>
+which uses a global and immutable table called the Static Pointer Table.
+The compiler includes entries in this table for all static forms found in
+the linked modules. The value can be obtained from the reference via
+<ulink url="&libraryBaseLocation;/GHC.StaticPtr.html#v%3AdeRefStaticPtr"><literal>deRefStaticPtr</literal></ulink>
+</para>
+
+<para>
+The body <literal>e</literal> of a <literal>static
+e</literal> expression must be a closed expression. That is, there can
+be no free variables occurring in <literal>e</literal>, i.e. lambda-
+or let-bound variables bound locally in the context of the expression.
+</para>
+
+<para>
+All of the following are permissible:
+<programlisting>
+inc :: Int -> Int
+inc x = x + 1
+
+ref1 = static 1
+ref2 = static inc
+ref3 = static (inc 1)
+ref4 = static ((\x -> x + 1) (1 :: Int))
+ref5 y = static (let x = 1 in x)
+</programlisting>
+While the following definitions are rejected:
+<programlisting>
+ref6 = let x = 1 in static x
+ref7 y = static (let x = 1 in y)
+</programlisting>
+</para>
+</sect2>
+
+<sect2 id="typechecking-static-pointers">
+<title>Static semantics of static pointers</title>
+
+<para>
+
+Informally, if we have a closed expression
+<programlisting>
+e :: forall a_1 ... a_n . t
+</programlisting>
+the static form is of type
+<programlisting>
+static e :: (Typeable a_1, ... , Typeable a_n) => StaticPtr t
+</programlisting>
+Furthermore, type <literal>t</literal> is constrained to have a
+<literal>Typeable</literal> instance.
+
+The following are therefore illegal:
+<programlisting>
+static show                    -- No Typeable instance for (Show a => a -> String)
+static Control.Monad.ST.runST  -- No Typeable instance for ((forall s. ST s a) -> a)
+</programlisting>
+
+That being said, with the appropriate use of wrapper datatypes, the
+above limitations induce no loss of generality:
+<programlisting>
+{-# LANGUAGE ConstraintKinds           #-}
+{-# LANGUAGE DeriveDataTypeable        #-}
+{-# LANGUAGE ExistentialQuantification #-}
+{-# LANGUAGE Rank2Types                #-}
+{-# LANGUAGE StandaloneDeriving        #-}
+{-# LANGUAGE StaticPointers            #-}
+
+import Control.Monad.ST
+import Data.Typeable
+import GHC.StaticPtr
+
+data Dict c = c => Dict
+  deriving Typeable
+
+g1 :: Typeable a => StaticPtr (Dict (Show a) -> a -> String)
+g1 = static (\Dict -> show)
+
+data Rank2Wrapper f = R2W (forall s. f s)
+  deriving Typeable
+newtype Flip f a s = Flip { unFlip :: f s a }
+  deriving Typeable
+
+g2 :: Typeable a => StaticPtr (Rank2Wrapper (Flip ST a) -> a)
+g2 = static (\(R2W f) -> runST (unFlip f))
+</programlisting>
+</para>
+</sect2>
+
+</sect1>
+
 
 <!-- =============================== PRAGMAS ===========================  -->
 
@@ -9909,11 +10861,11 @@
       A comma denotes conjunction, i.e. both sides are required.
       Conjunction binds stronger than disjunction.</para>
       <para>
-      If no MINIMAL pragma is given in the class declaration, it is just as if 
+      If no MINIMAL pragma is given in the class declaration, it is just as if
       a pragma <literal>{-# MINIMAL op1, op2, ..., opn #-}</literal> was given, where
-      the <literal>opi</literal> are the methods 
-      (a) that lack a default method in the class declaration, and 
-      (b) whose name that does not start with an underscore  
+      the <literal>opi</literal> are the methods
+      (a) that lack a default method in the class declaration, and
+      (b) whose name that does not start with an underscore
       (c.f. <option>-fwarn-missing-methods</option>, <xref linkend="options-sanity"/>).
       </para>
       <para>This warning can be turned off with the flag <option>-fno-warn-missing-methods</option>.</para>
@@ -10229,6 +11181,11 @@
       42 in the original.  GHC will adjust its error messages to refer
       to the line/file named in the <literal>LINE</literal>
       pragma.</para>
+
+      <para><literal>LINE</literal> pragmas generated from Template Haskell set
+      the file and line position for the duration of the splice and are limited
+      to the splice. Note that because Template Haskell splices abstract syntax,
+      the file positions are not automatically advanced.</para>
     </sect2>
 
     <sect2 id="rules">
@@ -10568,6 +11525,23 @@
      </para>
 </sect2>
 
+<sect2 id="overlap-pragma">
+<title>OVERLAPPING, OVERLAPPABLE, OVERLAPS, and INCOHERENT pragmas</title>
+<para>
+The pragmas
+  <literal>OVERLAPPING</literal>,
+  <literal>OVERLAPPABLE</literal>,
+  <literal>OVERLAPS</literal>,
+  <literal>INCOHERENT</literal> are used to specify the overlap
+behavior for individual instances, as described in Section
+<xref linkend="instance-overlap"/>.  The pragmas are written immediately
+after the <literal>instance</literal> keyword, like this:
+</para>
+<programlisting>
+instance {-# OVERLAPPING #-} C t where ...
+</programlisting>
+</sect2>
+
 </sect1>
 
 <!--  ======================= REWRITE RULES ======================== -->
@@ -10844,8 +11818,8 @@
 
 </sect2>
 
-<sect2 id="conlike">
-<title>How rules interact with INLINE/NOINLINE and CONLIKE pragmas</title>
+<sect2 id="rules-inline">
+<title>How rules interact with INLINE/NOINLINE pragmas</title>
 
 <para>
 Ordinary inlining happens at the same time as rule rewriting, which may lead to unexpected
@@ -10871,7 +11845,14 @@
 The way to get predictable behaviour is to use a NOINLINE
 pragma, or an INLINE[<replaceable>phase</replaceable>] pragma, on <literal>f</literal>, to ensure
 that it is not inlined until its RULEs have had a chance to fire.
+The warning flag <option>-fwarn-inline-rule-shadowing</option> (see <xref linkend="options-sanity"/>)
+warns about this situation.
 </para>
+</sect2>
+
+<sect2 id="conlike">
+<title>How rules interact with CONLIKE pragmas</title>
+
 <para>
 GHC is very cautious about duplicating work.  For example, consider
 <programlisting>
@@ -11216,69 +12197,6 @@
 
 </sect2>
 
-<sect2 id="core-pragma">
-  <title>CORE pragma</title>
-
-  <indexterm><primary>CORE pragma</primary></indexterm>
-  <indexterm><primary>pragma, CORE</primary></indexterm>
-  <indexterm><primary>core, annotation</primary></indexterm>
-
-<para>
-  The external core format supports <quote>Note</quote> annotations;
-  the <literal>CORE</literal> pragma gives a way to specify what these
-  should be in your Haskell source code.  Syntactically, core
-  annotations are attached to expressions and take a Haskell string
-  literal as an argument.  The following function definition shows an
-  example:
-
-<programlisting>
-f x = ({-# CORE "foo" #-} show) ({-# CORE "bar" #-} x)
-</programlisting>
-
-  Semantically, this is equivalent to:
-
-<programlisting>
-g x = show x
-</programlisting>
-</para>
-
-<para>
-  However, when external core is generated (via
-  <option>-fext-core</option>), there will be Notes attached to the
-  expressions <function>show</function> and <varname>x</varname>.
-  The core function declaration for <function>f</function> is:
-</para>
-
-<programlisting>
-  f :: %forall a . GHCziShow.ZCTShow a ->
-                   a -> GHCziBase.ZMZN GHCziBase.Char =
-    \ @ a (zddShow::GHCziShow.ZCTShow a) (eta::a) ->
-        (%note "foo"
-         %case zddShow %of (tpl::GHCziShow.ZCTShow a)
-           {GHCziShow.ZCDShow
-            (tpl1::GHCziBase.Int ->
-                   a ->
-                   GHCziBase.ZMZN GHCziBase.Char -> GHCziBase.ZMZN GHCziBase.Cha
-r)
-            (tpl2::a -> GHCziBase.ZMZN GHCziBase.Char)
-            (tpl3::GHCziBase.ZMZN a ->
-                   GHCziBase.ZMZN GHCziBase.Char -> GHCziBase.ZMZN GHCziBase.Cha
-r) ->
-              tpl2})
-        (%note "bar"
-         eta);
-</programlisting>
-
-<para>
-  Here, we can see that the function <function>show</function> (which
-  has been expanded out to a case expression over the Show dictionary)
-  has a <literal>%note</literal> attached to it, as does the
-  expression <varname>eta</varname> (which used to be called
-  <varname>x</varname>).
-</para>
-
-</sect2>
-
 </sect1>
 
 <sect1 id="special-ids">
@@ -11294,6 +12212,10 @@
 <ulink url="&libraryBaseLocation;/GHC-Exts.html#v%3Alazy"><literal>lazy</literal></ulink>
 restrains the strictness analyser.
 </para></listitem>
+<listitem><para>
+<ulink url="&libraryBaseLocation;/GHC-Exts.html#v%3AoneShot"><literal>oneShot</literal></ulink>
+gives a hint to the compiler about how often a function is being called.
+</para></listitem>
 </itemizedlist>
 </para>
 </sect1>
@@ -11317,8 +12239,9 @@
 
 <para>
 Using a combination of <option>-XDeriveGeneric</option>
-(<xref linkend="deriving-typeable"/>) and
+(<xref linkend="deriving-typeable"/>),
 <option>-XDefaultSignatures</option> (<xref linkend="class-default-signatures"/>),
+and <option>-XDeriveAnyClass</option> (<xref linkend="derive-any-class"/>),
 you can easily do datatype-generic
 programming using the <literal>GHC.Generics</literal> framework. This section
 gives a very brief overview of how to do it.
@@ -11494,6 +12417,10 @@
 The default method for <literal>put</literal> is then used, corresponding to the
 generic implementation of serialization.
 
+If you are using <option>-XDeriveAnyClass</option>, the same instance is
+generated by simply attaching a <literal>deriving Serialize</literal> clause
+to the <literal>UserTree</literal> datatype declaration.
+
 For more examples of generic functions please refer to the
 <ulink url="http://hackage.haskell.org/package/generic-deriving">generic-deriving</ulink>
 package on Hackage.
@@ -11572,7 +12499,7 @@
 url="http://www.seas.upenn.edu/~sweirich/papers/popl163af-weirich.pdf">Generative
 type abstraction and type-level computation</ulink>, published at POPL 2011.</para>
 
-<sect2>
+<sect2 id="nominal-representational-and-phantom">
 <title>Nominal, Representational, and Phantom</title>
 
 <para>The goal of the roles system is to track when two types have the same
@@ -11629,7 +12556,7 @@
 
 </sect2>
 
-<sect2>
+<sect2 id="role-inference">
 <title>Role inference</title>
 
 <para>
@@ -11683,7 +12610,7 @@
 
 </sect2>
 
-<sect2>
+<sect2 id="role-annotations">
 <title>Role annotations
 <indexterm><primary>-XRoleAnnotations</primary></indexterm>
 </title>
@@ -11733,14 +12660,18 @@
 </programlisting>
 
 <para>Role annotations can also be used should a programmer wish to write
-a class with a representational (or phantom) role.</para>
+a class with a representational (or phantom) role. However, as a class
+with non-nominal roles can quickly lead to class instance incoherence,
+it is necessary to also specify <option>-XIncoherentInstances</option>
+to allow non-nominal roles for classes.</para>
 
 <para>The other place where role annotations may be necessary are in
 <literal>hs-boot</literal> files (<xref linkend="mutual-recursion"/>), where
 the right-hand sides of definitions can be omitted. As usual, the
 types/classes declared in an <literal>hs-boot</literal> file must match up
 with the definitions in the <literal>hs</literal> file, including down to the
-roles. The default role is representational in <literal>hs-boot</literal> files,
+roles. The default role for datatypes
+is representational in <literal>hs-boot</literal> files,
 corresponding to the common use case.</para>
 
 <para>
@@ -11769,7 +12700,7 @@
   type role T4 nominal
   data T4 a = MkT4 (a Int) -- OK, but nominal is higher than necessary
 
-  type role C representational _
+  type role C representational _   -- OK, with -XIncoherentInstances
   class C a b where ...    -- OK, b will get a nominal role
 
   type role X nominal
diff -urd 7.8.2-original/gone_wrong.xml original/gone_wrong.xml
--- 7.8.2-original/gone_wrong.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/gone_wrong.xml	2016-04-09 21:36:11.394998369 +0900
@@ -146,7 +146,7 @@
           <emphasis>must</emphasis> be re-compiled.</para>
 
 	  <para>A useful option to alert you when interfaces change is
-          <option>-hi-diffs</option><indexterm><primary>-hi-diffs
+          <option>-ddump-hi-diffs</option><indexterm><primary>-ddump-hi-diffs
           option</primary></indexterm>.  It will run
           <command>diff</command> on the changed interface file,
           before and after, when applicable.</para>
@@ -167,7 +167,7 @@
 
 <screen>
 % rm *.o        # scrub your object files
-% make my_prog  # re-make your program; use -hi-diffs to highlight changes;
+% make my_prog  # re-make your program; use -ddump-hi-diffs to highlight changes;
                 # as mentioned above, use -dcore-lint to be more paranoid
 % ./my_prog ... # retry...
 </screen>
diff -urd 7.8.2-original/packages.xml original/packages.xml
--- 7.8.2-original/packages.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/packages.xml	2016-04-09 21:36:11.394998369 +0900
@@ -23,7 +23,7 @@
     automates the process of configuring, building, installing and distributing
     a package.  All you need to do is write a simple configuration file, put a
     few files in the right places, and you have a package.  See the
-    <ulink url="../Cabal/index.html">Cabal documentation</ulink>
+    <ulink url="http://www.haskell.org/cabal/users-guide/">Cabal documentation</ulink>
     for details, and also the Cabal libraries (<ulink url="&libraryCabalLocation;/Distribution-Simple.html">Distribution.Simple</ulink>,
     for example).</para>
 
@@ -88,7 +88,11 @@
       to expose a hidden package or hide an exposed one.  Only modules
       from exposed packages may be imported by your Haskell code; if
       you try to import a module from a hidden package, GHC will emit
-      an error message.
+      an error message.  If there are a multiple exposed versions of a package,
+      GHC will prefer the latest one.  Additionally, some packages may be
+      broken: that is, they are missing from the package database, or one of
+      their dependencies are broken; in this case; these packages are excluded
+      from the default set of packages.
     </para>
 
     <para>
@@ -137,8 +141,11 @@
             (e.g. <literal>network-1.0</literal>) or the version
             number can be omitted if there is only one version of the
             package installed. If there are multiple versions
-            of <replaceable>P</replaceable> installed, then all other
-            versions will become hidden.</para>
+            of <replaceable>P</replaceable> installed and
+            <option>-hide-all-packages</option> was not specified, then all
+            other versions will become hidden.  <option>-package</option>
+            supports thinning and renaming described in <xref
+            linkend="package-thinning-and-renaming" />.</para>
 
           <para>The <option>-package <replaceable>P</replaceable></option>
             option also causes package <replaceable>P</replaceable> to
@@ -183,10 +190,12 @@
         <listitem>
           <para>
             Exposes a package like <option>-package</option>, but the
-            package is named by its ID rather than by name.  This is a
+            package is named by its installed package ID rather than by name.  This is a
             more robust way to name packages, and can be used to
             select packages that would otherwise be shadowed.  Cabal
             passes <option>-package-id</option> flags to GHC.
+            <option>-package-id</option> supports thinning and renaming
+            described in <xref linkend="package-thinning-and-renaming" />.
           </para>
         </listitem>
       </varlistentry>
@@ -258,19 +267,15 @@
       </varlistentry>
 
       <varlistentry>
-        <term><option>-package-name</option> <replaceable>foo</replaceable>
-        <indexterm><primary><option>-package-name</option></primary>
+        <term><option>-this-package-key</option> <replaceable>foo</replaceable>
+        <indexterm><primary><option>-this-package-key</option></primary>
           </indexterm></term>
         <listitem>
           <para>Tells GHC the the module being compiled forms part of
-            package <replaceable>foo</replaceable>.
+            package key <replaceable>foo</replaceable>; internally, these
+            keys are used to determine type equality and linker symbols.
             If this flag is omitted (a very common case) then the
             default package <literal>main</literal> is assumed.</para>
-            <para>Note: the argument to <option>-package-name</option>
-              should be the full
-              package <literal>name-version</literal> for the package.
-              For example:
-            <literal>-package mypkg-1.2</literal>.</para>
         </listitem>
       </varlistentry>
 
@@ -328,7 +333,7 @@
 
   <para>Every complete Haskell program must define <literal>main</literal> in
    module <literal>Main</literal>
-   in package <literal>main</literal>.   (Omitting the <option>-package-name</option> flag compiles
+   in package <literal>main</literal>.   (Omitting the <option>-this-package-key</option> flag compiles
    code for package <literal>main</literal>.) Failure to do so leads to a somewhat obscure
    link-time error of the form:
 <programlisting>
@@ -367,6 +372,53 @@
     name.</para>
   </sect2>
 
+  <sect2 id="package-thinning-and-renaming">
+    <title>Thinning and renaming modules</title>
+
+  <para>When incorporating packages from multiple sources, you may end up
+  in a situation where multiple packages publish modules with the same name.
+  Previously, the only way to distinguish between these modules was to
+  use <xref linkend="package-qualified-imports" />. However, since GHC 7.10,
+  the <option>-package</option> flags (and their variants) have been extended
+  to allow a user to explicitly control what modules a package brings into
+  scope, by analogy to the import lists that users can attach to module imports.
+  </para>
+
+  <para>
+  The basic syntax is that instead of specifying a package name P to the package
+  flag <literal>-package</literal>, instead we specify both a package name and a
+  parenthesized, comma-separated list of module names to import.  For example,
+  <literal>-package "base (Data.List, Data.Bool)"</literal> makes only
+  <literal>Data.List</literal> and <literal>Data.Bool</literal> visible from
+  package <literal>base</literal>.  We also support renaming of modules, in case
+  you need to refer to both modules simultaneously; this is supporting by
+  writing <literal>OldModName as NewModName</literal>, e.g. <literal>-package
+  "base (Data.Bool as Bool)</literal>.  You can also write <literal>-package
+  "base with (Data.Bool as Bool)</literal> to include all of the original
+  bindings (e.g. the renaming is strictly additive).  It's important to specify
+  quotes so that your shell passes the package name and thinning/renaming list
+  as a single argument to GHC.</para>
+
+  <para>Package imports with thinning/renaming do not hide other versions of the
+  package: e.g. if containers-0.9 is already exposed, <literal>-package
+  "containers-0.8 (Data.List as ListV8)"</literal> will only add an additional
+  binding to the environment.  Similarly, <literal>-package "base (Data.Bool as
+  Bool)" -package "base (Data.List as List)"</literal> is equivalent to
+  <literal>-package "base (Data.Bool as Bool, Data.List as List)"</literal>.
+  Literal names must refer to modules defined by the original package, so for
+  example <literal>-package "base (Data.Bool as Bool, Bool as Baz)"</literal> is
+  invalid unless there was a <literal>Bool</literal> module defined in the
+  original package.  Hiding a package also clears all of its renamings.  </para>
+
+  <para>
+  You can use renaming to provide an alternate prelude, e.g.
+  <literal>-hide-all-packages -package "basic-prelude (BasicPrelude as
+  Prelude)"</literal>, in lieu of the <xref
+  linkend="rebindable-syntax">NoImplicitPrelude</xref> extension.
+  </para>
+
+  </sect2>
+
   <sect2 id="package-databases">
     <title>Package Databases</title>
 
@@ -528,12 +580,11 @@
   </sect2>
 
   <sect2 id="package-ids">
-    <title>Package IDs, dependencies, and broken packages</title>
+    <title>Installed package IDs, dependencies, and broken packages</title>
 
     <para>Each installed package has a unique identifier (the
-      &ldquo;installed package ID&rdquo;, or just &ldquo;package
-      ID&rdquo; for short) , which distinguishes it from all other
-      installed packages on the system.  To see the package IDs
+      &ldquo;installed package ID&rdquo;), which distinguishes it from all other
+      installed packages on the system.  To see the installed package IDs
       associated with each installed package, use <literal>ghc-pkg
       list -v</literal>:</para>
 
@@ -549,10 +600,10 @@
 </screen>
 
     <para>
-      The string in parentheses after the package name is the package
+      The string in parentheses after the package name is the installed package
       ID: it normally begins with the package name and version, and
       ends in a hash string derived from the compiled package.
-      Dependencies between packages are expressed in terms of package
+      Dependencies between packages are expressed in terms of installed package
       IDs, rather than just packages and versions.  For example, take
       a look at the dependencies of the <literal>haskell98</literal>
       package:
@@ -570,14 +621,14 @@
 </screen>
 
     <para>
-      The purpose of the package ID is to detect problems caused by
+      The purpose of the installed package ID is to detect problems caused by
       re-installing a package without also recompiling the packages
       that depend on it.  Recompiling dependencies is necessary,
       because the newly compiled package may have a different ABI
       (Application Binary Interface) than the previous version, even
       if both packages were built from the same source code using the
-      same compiler.  With package IDs, a recompiled
-      package will have a different package ID from the previous
+      same compiler.  With installed package IDs, a recompiled
+      package will have a different installed package ID from the previous
       version, so packages that depended on the previous version are
       now orphaned - one of their dependencies is not satisfied.
       Packages that are broken in this way are shown in
@@ -691,7 +742,9 @@
       package; the specified action will be applied to all the matching
       packages.  A package specifier that matches all version of the package
       can also be written <replaceable>pkg</replaceable><literal>-*</literal>,
-      to make it clearer that multiple packages are being matched.</para>
+      to make it clearer that multiple packages are being matched.  To match
+      against the installed package ID instead of just package name and version,
+      pass the <option>--ipid</option> flag.</para>
 
     <variablelist>
       <varlistentry>
@@ -1047,8 +1100,25 @@
           <para>Output the <literal>ghc-pkg</literal> version number.</para>
         </listitem>
       </varlistentry>
-    </variablelist>
 
+      <varlistentry>
+        <term>
+          <option>--ipid</option>
+          <indexterm><primary>
+              <option>--ipid</option>
+            </primary></indexterm>
+        </term>
+        <listitem>
+          <para>Causes <literal>ghc-pkg</literal> to interpret arguments
+          as installed package IDs (e.g., an identifier like
+          <literal>unix-2.3.1.0-de7803f1a8cd88d2161b29b083c94240
+          </literal>).  This is useful if providing just the package
+          name and version are ambiguous (in old versions of GHC, this
+          was guaranteed to be unique, but this invariant no longer
+          necessarily holds).</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
   </sect2>
 
   <sect2 id="building-packages">
@@ -1057,7 +1127,7 @@
       <secondary>building</secondary></indexterm>
 
     <para>We don't recommend building packages the hard way.  Instead, use the
-      <ulink url="../Cabal/index.html">Cabal</ulink> infrastructure
+      <ulink url="http://www.haskell.org/cabal/users-guide/">Cabal</ulink> infrastructure
       if possible.  If your package is particularly complicated or requires a
       lot of configuration, then you might have to fall back to the low-level
       mechanisms, so a few hints for those brave souls follow.</para>
@@ -1152,8 +1222,8 @@
     </itemizedlist>
 
      <para>To compile a module which is to be part of a new package,
-      use the <literal>-package-name</literal> option (<xref linkend="using-packages"/>).
-      Failure to use the <literal>-package-name</literal> option
+      use the <literal>-this-package-key</literal> option (<xref linkend="using-packages"/>).
+      Failure to use the <literal>-this-package-key</literal> option
       when compiling a package will probably result in disaster, but
       you will only discover later when you attempt to import modules
       from the package.  At this point GHC will complain that the
@@ -1288,7 +1358,7 @@
           <indexterm><primary><literal>id</literal></primary><secondary>package specification</secondary></indexterm>
         </term>
         <listitem>
-          <para>The package ID.  It is up to you to choose a suitable
+          <para>The installed package ID.  It is up to you to choose a suitable
           one.</para>
         </listitem>
       </varlistentry>
@@ -1447,6 +1517,25 @@
 
         <varlistentry>
           <term>
+            <literal>reexported-modules</literal>
+            <indexterm><primary><literal>reexported-modules</literal></primary><secondary>reexport specification</secondary></indexterm>
+          </term>
+          <listitem>
+            <para>Modules reexported by this package.  This list takes
+            the form of <literal>pkg:OldName as NewName
+            (A@orig-pkg-0.1-HASH)</literal>: the first portion of the
+            string is the user-written reexport specification (possibly
+            omitting the package qualifier and the renaming), while the
+            parenthetical is the original package which exposed the
+            module under are particular name.  Reexported modules have
+            a relaxed overlap constraint: it's permissible for two
+            packages to reexport the same module as the same name if the
+            reexported moduleis identical.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
             <literal>trusted</literal>
             <indexterm><primary><literal>trusted</literal></primary><secondary>package specification</secondary></indexterm>
           </term>
@@ -1723,6 +1812,92 @@
 -->
 
     </sect2>
+    <sect2 id="package-environments">
+    <indexterm><primary>package environments</primary></indexterm>
+    <title>
+      Package environments
+    </title>
+    <para>
+      A <emphasis>package environment</emphasis> is a file that tells
+      <literal>ghc</literal> precisely which packages should be visible. It
+      contains package IDs, one per line:
+    </para>
+<screen>
+package_id_1
+package_id_2
+...
+package_id_n
+</screen>
+    <para>
+      If a package environment is found, it is equivalent to passing these
+      command line arguments to <literal>ghc</literal>:
+    </para>
+<screen>
+-hide-all-packages
+-package-id package_id_1
+-package-id package_id_2
+...
+-package-id package_id_n
+</screen>
+    <para>
+      In order, <literal>ghc</literal> will look for the package environment
+      in the following locations:
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+          File
+            <replaceable>file</replaceable>
+          if you pass the option
+            <option>-package-env <replaceable>file</replaceable></option>.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          File
+            <filename>$HOME/.ghc/<replaceable>arch</replaceable>-<replaceable>os</replaceable>-<replaceable>version</replaceable>/environments/<replaceable>name</replaceable></filename>
+          if you pass the option
+            <option>-package-env <replaceable>name</replaceable></option>.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          File
+            <replaceable>file</replaceable>
+          if the environment variable <literal>GHC_ENVIRONMENT</literal>
+          is set to <replaceable>file</replaceable>.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          File
+            <filename>$HOME/.ghc/<replaceable>arch</replaceable>-<replaceable>os</replaceable>-<replaceable>version</replaceable>/environments/<replaceable>name</replaceable></filename>
+          if the environment variable <literal>GHC_ENVIRONMENT</literal>
+          is set to <replaceable>name</replaceable>.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          File <filename>./.ghc.environment</filename> if it exists.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          File
+            <filename>$HOME/.ghc/<replaceable>arch</replaceable>-<replaceable>os</replaceable>-<replaceable>version</replaceable>/environments/default</filename>
+          if it exists.
+        </para>
+      </listitem>
+    </itemizedlist>
+    <para>
+      Package environments can be modified by further command line arguments;
+      for example, if you specify
+        <option>-package <replaceable>foo</replaceable></option>
+      on the command line, then package <replaceable>foo</replaceable> will be
+      visible even if it's not listed in the currently active package
+      environment.
+    </para>
+    </sect2>
   </sect1>
 
 <!-- Emacs stuff:
diff -urd 7.8.2-original/parallel.xml original/parallel.xml
--- 7.8.2-original/parallel.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/parallel.xml	2016-04-09 21:36:11.394998369 +0900
@@ -30,7 +30,7 @@
   <para>Concurrent Haskell is the name given to GHC's concurrency extension.
   It is enabled by default, so no special flags are required.
    The <ulink
-	      url="http://research.microsoft.com/copyright/accept.asp?path=/users/simonpj/papers/concurrent-haskell.ps.gz">
+	      url="https://www.haskell.org/ghc/docs/papers/concurrent-haskell.ps.gz">
 	      Concurrent Haskell paper</ulink> is still an excellent
 	      resource, as is <ulink
 	      url="http://research.microsoft.com/%7Esimonpj/papers/marktoberdorf/">Tackling
@@ -94,7 +94,7 @@
     (GPH) supports running Parallel Haskell
     programs on both clusters of machines, and single multiprocessors.  GPH is
     developed and distributed
-    separately from GHC (see <ulink url="http://www.cee.hw.ac.uk/~dsg/gph/">The
+    separately from GHC (see <ulink url="http://www.macs.hw.ac.uk/~dsg/gph/">The
       GPH Page</ulink>).  However, the current version of GPH is based on a much older
     version of GHC (4.06).</para>
 
diff -urd 7.8.2-original/phases.xml original/phases.xml
--- 7.8.2-original/phases.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/phases.xml	2016-04-09 21:36:11.395998334 +0900
@@ -148,6 +148,17 @@
           (when using <option>-staticlib</option> only).</para>
         </listitem>
       </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>-pgmreadelf</option> <replaceable>cmd</replaceable>
+          <indexterm><primary><option>-pgmreadelf</option></primary></indexterm>
+        </term>
+        <listitem>
+          <para>Use <replaceable>cmd</replaceable> as the readelf command
+          (part of Unix binutils).</para>
+        </listitem>
+      </varlistentry>
     </variablelist>
   </sect2>
 
@@ -218,15 +229,6 @@
       </varlistentry>
       <varlistentry>
         <term>
-          <option>-optm</option>  <replaceable>option</replaceable>
-          <indexterm><primary><option>-optm</option></primary></indexterm>
-        </term>
-        <listitem>
-          <para>Pass <replaceable>option</replaceable> to the mangler.</para>
-        </listitem>
-      </varlistentry>
-      <varlistentry>
-        <term>
           <option>-opta</option>  <replaceable>option</replaceable>
           <indexterm><primary><option>-opta</option></primary></indexterm>
         </term>
@@ -398,6 +400,100 @@
 
       <varlistentry>
         <term>
+          <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL1&lowbar;&lowbar;</constant>
+          <indexterm><primary><constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL1&lowbar;&lowbar;</constant></primary></indexterm>
+        </term>
+        <term>
+          <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL2&lowbar;&lowbar;</constant>
+          <indexterm><primary><constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL2&lowbar;&lowbar;</constant></primary></indexterm>
+        </term>
+        <listitem>
+          <para>These macros are available starting with GHC 7.10.1.</para>
+
+          <para>For three-part GHC version numbers
+          <literal><replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable></literal>,
+          the value of
+          <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL1&lowbar;&lowbar;</constant>
+          is the integer <replaceable>z</replaceable>.</para>
+
+          <para>For four-part GHC version numbers
+          <literal><replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>.<replaceable>z'</replaceable></literal>,
+          the value of
+          <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL1&lowbar;&lowbar;</constant>
+          is the integer <replaceable>z</replaceable> while the value of
+          <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;PATCHLEVEL2&lowbar;&lowbar;</constant>
+          is set to the integer <replaceable>z'</replaceable>.</para>
+
+          <para>These macros are provided for allowing finer
+          granularity than is provided by
+          <literal>__GLASGOW_HASKELL__</literal>. Usually, this should
+          not be necessary as it's expected for most APIs to remain
+          stable between patchlevel releases, but occasionally
+          internal API changes are necessary to fix bugs.  Also
+          conditional compilation on the patchlevel can be useful for
+          working around bugs in older releases.</para>
+
+          <para>NB. These macros are set when pre-processing both
+          Haskell source and C source, including the C source
+          generated from a Haskell module
+          (i.e. <filename>.hs</filename>, <filename>.lhs</filename>,
+          <filename>.c</filename> and <filename>.hc</filename>
+          files).</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <constant>MIN&lowbar;VERSION&lowbar;GLASGOW&lowbar;HASKELL(<replaceable>x</replaceable>,<replaceable>y</replaceable>,<replaceable>z</replaceable>,<replaceable>z'</replaceable>)</constant>
+          <indexterm><primary><constant>MIN&lowbar;VERSION&lowbar;GLASGOW&lowbar;HASKELL</constant></primary></indexterm>
+        </term>
+        <listitem>
+          <para>This macro is available starting with GHC 7.10.1.</para>
+
+          <para>This macro is provided for convenience to write CPP
+          conditionals testing whether the GHC version used is version
+          <literal><replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>.<replaceable>z'</replaceable></literal>
+          or later.</para>
+
+          <para>If compatibility with Haskell compilers (including GHC
+          prior to version 7.10.1) which do not define
+          <literal>MIN_VERSION_GLASGOW_HASKELL</literal> is required,
+          the presence of the
+          <literal>MIN_VERSION_GLASGOW_HASKELL</literal> macro needs
+          to be ensured before it is called, e.g.:</para>
+
+<programlisting>&num;ifdef MIN_VERSION_GLASGOW_HASKELL
+&num;if MIN_VERSION_GLASGOW_HASKELL(7,10,2,0)
+/* code that applies only to GHC 7.10.2 or later */
+&num;endif
+&num;endif</programlisting>
+
+          <para>NB. This macro is set when pre-processing both
+          Haskell source and C source, including the C source
+          generated from a Haskell module
+          (i.e. <filename>.hs</filename>, <filename>.lhs</filename>,
+          <filename>.c</filename> and <filename>.hc</filename>
+          files).</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;TH&lowbar;&lowbar;</constant>
+          <indexterm><primary><constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;TH&lowbar;&lowbar;</constant></primary></indexterm>
+        </term>
+        <listitem>
+          <para>
+          This is set to <literal>YES</literal> when the compiler supports Template Haskell, and to
+          <literal>NO</literal> when not. The latter is the case for a stage-1 compiler during bootstrapping, or
+          on architectures where the interpreter is not available.
+          </para>
+        </listitem>
+      </varlistentry>
+
+
+      <varlistentry>
+        <term>
           <constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;LLVM&lowbar;&lowbar;</constant>
           <indexterm><primary><constant>&lowbar;&lowbar;GLASGOW&lowbar;HASKELL&lowbar;LLVM&lowbar;&lowbar;</constant></primary></indexterm>
         </term>
@@ -585,8 +681,22 @@
         </term>
         <listitem>
           <para>Omit code generation (and all later phases)
-          altogether.  Might be of some use if you just want to see
-          dumps of the intermediate compilation phases.</para>
+          altogether.  This is useful if you're only interested in
+          type checking code.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>-fwrite-interface</option>
+          <indexterm><primary><option>-fwrite-interface</option></primary></indexterm>
+        </term>
+        <listitem>
+          <para>Always write interface files.  GHC will normally write
+          interface files automatically, but this flag is useful with
+          <option>-fno-code</option>, which normally suppresses generation
+          of interface files.  This is useful if you want to type check
+          over multiple runs of GHC without compiling dependencies.</para>
         </listitem>
       </varlistentry>
 
@@ -794,10 +904,10 @@
           executables linked against the library are smaller as they only
           link against the object files that they need. However, assembling
           all the sections separately is expensive, so this is slower than
-          compiling normally.
-          We use this feature for building GHC's libraries
-          (warning: don't use it unless you know what you're
-          doing!).</para>
+          compiling normally. Additionally, the size of the library itself
+          (the <literal>.a</literal> file) can be a factor of 2 to 2.5
+          larger.
+          We use this feature for building GHC's libraries.</para>
         </listitem>
       </varlistentry>
 
@@ -1225,6 +1335,21 @@
               platforms.</para>
         </listitem>
       </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>-rdynamic</option>
+          <indexterm><primary><option>-rdynamic</option></primary>
+          </indexterm>
+        </term>
+        <listitem>
+          <para>
+              This instructs the linker to add all symbols, not only used ones, to the
+              dynamic symbol table. Currently Linux and Windows/MinGW32 only.
+              This is equivalent to using <literal>-optl -rdynamic</literal> on Linux,
+              and <literal>-optl -export-all-symbols</literal> on Windows.</para>
+        </listitem>
+      </varlistentry>
     </variablelist>
   </sect2>
 
7.8.2-original のみに存在: prof_scc.png
diff -urd 7.8.2-original/profiling.xml original/profiling.xml
--- 7.8.2-original/profiling.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/profiling.xml	2016-04-09 21:36:11.395998334 +0900
@@ -625,7 +625,7 @@
            other than making the PS file generation work, rather than
            falling over.  The result seems to be broken PS on the page
            with the image. -->
-      <imagedata fileref="prof_scc" contentwidth="645px"
+      <imagedata fileref="prof_scc.eps" contentwidth="645px"
       contentdepth="428px"/>
 
     <para>You might also want to take a look
@@ -1771,7 +1771,7 @@
 
     <para>Because ticky-ticky profiling requires a certain familiarity
     with GHC internals, we have moved the documentation to the
-    wiki. Take a look at its <ulink
+    GHC developers wiki. Take a look at its <ulink
     url="http://ghc.haskell.org/trac/ghc/wiki/Commentary/Profiling">overview
     of the profiling options</ulink>, which includeds a link to the
     ticky-ticky profiling page.</para>
diff -urd 7.8.2-original/runtime_control.xml original/runtime_control.xml
--- 7.8.2-original/runtime_control.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/runtime_control.xml	2016-04-09 21:36:11.395998334 +0900
@@ -323,6 +323,26 @@
          </para>
        </listitem>
      </varlistentry>
+
+     <varlistentry>
+       <term><option>-xq<replaceable>size</replaceable></option>
+       <indexterm><primary><option>-xq</option></primary><secondary>RTS
+       option</secondary></indexterm></term>
+       <listitem>
+         <para>
+           &lsqb;Default: 100k&rsqb; This option relates to allocation
+           limits; for more about this see <ulink
+           url="&libraryBaseLocation;/GHC-Conc.html#v%3AenableAllocationLimit"><literal>enableAllocationLimit</literal></ulink>.
+           When a thread hits its allocation limit, the RTS throws an
+           exception to the thread, and the thread gets an additional
+           quota of allocation before the exception is raised again,
+           the idea being so that the thread can execute its exception
+           handlers.  The <option>-xq</option> controls the size of
+           this additional quota.
+         </para>
+       </listitem>
+     </varlistentry>
+
     </variablelist>
   </sect2>
 
@@ -365,6 +385,42 @@
       </varlistentry>
 
       <varlistentry>
+        <term>
+          <option>-n</option><replaceable>size</replaceable>
+          <indexterm><primary><option>-n</option></primary><secondary>RTS option</secondary></indexterm>
+          <indexterm><primary>allocation area, chunk size</primary></indexterm>
+        </term>
+	<listitem>
+          <para>&lsqb;Default: 0, Example:
+          <literal>-n4m</literal>&rsqb; When set to a non-zero value,
+          this option divides the allocation area (<option>-A</option>
+          value) into chunks of the specified size.  During execution,
+          when a processor exhausts its current chunk, it is given
+          another chunk from the pool until the pool is exhausted, at
+          which point a collection is triggered.</para>
+
+          <para>This option is only useful when running in parallel
+          (<option>-N2</option> or greater).  It allows the processor
+          cores to make better use of the available allocation area,
+          even when cores are allocating at different rates.  Without
+          <option>-n</option>, each core gets a fixed-size allocation
+          area specified by the <option>-A</option>, and the first
+          core to exhaust its allocation area triggers a GC across all
+          the cores.  This can result in a collection happening when
+          the allocation areas of some cores are only partially full,
+          so the purpose of the <option>-n</option> is to allow cores
+          that are allocating faster to get more of the allocation
+          area.  This means less frequent GC, leading a lower GC
+          overhead for the same heap size.</para>
+
+          <para>This is particularly useful in conjunction with larger
+          <option>-A</option> values, for example <option>-A64m
+          -n4m</option> is a useful combination on larger core counts
+          (8+).</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
 	<term>
           <option>-c</option>
           <indexterm><primary><option>-c</option></primary><secondary>RTS option</secondary></indexterm>
@@ -1442,8 +1498,7 @@
           <literal>-threaded</literal> option) and <literal>rts_p</literal>
           (profiling runtime, i.e. linked using the <literal>-prof</literal>
           option). Other variants include <literal>debug</literal>
-          (linked using <literal>-debug</literal>),
-          <literal>t</literal> (ticky-ticky profiling) and
+          (linked using <literal>-debug</literal>), and
           <literal>dyn</literal> (the RTS is
           linked in dynamically, i.e. a shared library, rather than statically
           linked into the executable itself). These can be combined,
diff -urd 7.8.2-original/safe_haskell.xml original/safe_haskell.xml
--- 7.8.2-original/safe_haskell.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/safe_haskell.xml	2016-04-09 21:36:11.394998369 +0900
@@ -705,7 +705,7 @@
       </varlistentry>
     </variablelist>
 
-    And two warning flags:
+    And three warning flags:
 
     <variablelist>
       <varlistentry>
@@ -724,6 +724,15 @@
           when using safe inference.
         </listitem>
       </varlistentry>
+      <varlistentry>
+        <term>-fwarn-trustworthy-safe</term>
+        <indexterm><primary>-fwarn-trustworthy-safe</primary></indexterm>
+        <listitem>Issue a warning if the module being compiled is marked as
+          <option>-XTrustworthy</option> but it could instead be marked as
+          <option>-XSafe</option>, a more informative bound. Can be used to
+          detect once a Safe Haskell bound can be improved as dependencies are
+          updated.</listitem>
+      </varlistentry>
     </variablelist>
   </sect2>
 
@@ -767,6 +776,12 @@
       Wiki</ulink>.
     </para>
 
+    <para>
+    Additionally, the use of <link linkend="annotations">annotations</link>
+    is forbidden, as that would allow bypassing Safe Haskell restrictions.
+    See <ulink url="https://ghc.haskell.org/trac/ghc/ticket/10826">ticket #10826</ulink>.
+    </para>
+
   </sect2>
 
 </sect1>
diff -urd 7.8.2-original/separate_compilation.xml original/separate_compilation.xml
--- 7.8.2-original/separate_compilation.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/separate_compilation.xml	2016-04-09 21:36:11.395998334 +0900
@@ -883,6 +883,100 @@
 </para>
     </sect2>
 
+    <sect2 id="module-signatures">
+      <title>Module signatures</title>
+      <para>GHC supports the specification of module signatures, which
+      both implementations and users can typecheck against separately.
+      This functionality should be considered experimental for now; some
+      details, especially for type classes and type families, may change.
+      This system was originally described in <ulink
+      url="http://plv.mpi-sws.org/backpack/">Backpack: Retrofitting Haskell with
+      Interfaces</ulink>.  Signature files are somewhat similar to
+      <literal>hs-boot</literal> files, but have the <literal>hsig</literal>
+      extension and behave slightly differently.
+      </para>
+
+      <para>Suppose that I have modules <filename>String.hs</filename> and
+      <filename>A.hs</filename>, thus:</para>
+
+<programlisting>
+module Text where
+    data Text = Text String
+
+    empty :: Text
+    empty = Text ""
+
+    toString :: Text -> String
+    toString (Text s) = s
+
+module A where
+    import Text
+    z = toString empty
+</programlisting>
+
+      <para>Presently, module <literal>A</literal> depends explicitly on
+      a concrete implementation of <literal>Text</literal>.  What if we wanted
+      to a signature <literal>Text</literal>, so we could vary the
+      implementation with other possibilities (e.g. packed UTF-8 encoded
+      bytestrings)?  To do this, we can write a signature
+      <filename>TextSig.hsig</filename>, and modify <literal>A</literal>
+      to include the signature instead:
+      </para>
+
+<programlisting>
+module TextSig where
+    data Text
+    empty :: Text
+    toString :: Text -> String
+
+module A where
+    import TextSig
+    z = toString empty
+</programlisting>
+
+      <para>To compile these two files, we need to specify what module we
+      would like to use to implement the signature.  This can be done by
+      compiling the implementation, and then using the <literal>-sig-of</literal>
+      flag to specify the implementation backing a signature:</para>
+
+<programlisting>
+ghc -c Text.hs
+ghc -c TextSig.hsig -sig-of main:Text
+ghc -c A.hs
+</programlisting>
+
+      <para>Signature files can also be compiled as part of
+      <literal>--make</literal>, in which case the syntax is extended
+      to support specifying implementations of multiple signatures
+      as <literal>FooSig is main:Foo, BarSig is main:Bar</literal>.
+      At the moment, you must specify the full module name (package key,
+      colon, and then module name), although in the future we may support
+      more user-friendly syntax.</para>
+
+      <para>To just type-check an interface file, no <literal>-sig-of</literal>
+      is necessary; instead, just pass the options
+      <literal>-fno-code -fwrite-interface</literal>.  <literal>hsig</literal>
+      files will generate normal interface files which other files can
+      also use to type-check against.  However, at the moment, we always
+      assume that an entity defined in a signature is a unique identifier
+      (even though we may happen to know it is type equal with another
+      identifier).  In the future, we will support passing shaping information
+      to the compiler in order to let it know about these type
+      equalities.</para>
+
+      <para>Just like <literal>hs-boot</literal> files, when an
+      <literal>hsig</literal> file is compiled it is checked for type
+      consistency against the backing implementation.  Signature files are also
+      written in a subset of Haskell essentially identical to that of
+      <literal>hs-boot</literal> files.</para>
+
+      <para>There is one important gotcha with the current implementation:
+      currently, instances from backing implementations will "leak" code that
+      uses signatures, and explicit instance declarations in signatures are
+      forbidden.  This behavior will be subject to change.</para>
+
+    </sect2>
+
 
     <sect2 id="using-make">
       <title>Using <command>make</command></title>
diff -urd 7.8.2-original/ug-book.xml original/ug-book.xml
--- 7.8.2-original/ug-book.xml	2014-06-27 09:31:23.000000000 +0900
+++ original/ug-book.xml	2016-04-09 21:36:11.395998334 +0900
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="iso-8859-1"?>
 <bookinfo>
-<title>The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.8.2</title>
+<title>The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.10.3</title>
 <author><othername>The GHC Team</othername></author>
 <address>
 <email>glasgow-haskell-users-request@haskell.org</email>
diff -urd 7.8.2-original/ug-ent.xml original/ug-ent.xml
--- 7.8.2-original/ug-ent.xml	2014-06-27 09:31:23.000000000 +0900
+++ original/ug-ent.xml	2016-04-09 21:36:11.395998334 +0900
@@ -13,7 +14,6 @@
 <!ENTITY sooner         SYSTEM "sooner.xml" >
 <!ENTITY lang-features  SYSTEM "lang.xml" >
 <!ENTITY glasgowexts    SYSTEM "glasgow_exts.xml" >
-<!ENTITY external-core  SYSTEM "external_core.xml" >
 <!ENTITY packages       SYSTEM "packages.xml" >
 <!ENTITY parallel       SYSTEM "parallel.xml" >
 <!ENTITY safehaskell    SYSTEM "safe_haskell.xml" >
@@ -27,7 +27,7 @@
 <!ENTITY ffi-chap       SYSTEM "ffi-chap.xml">
 <!ENTITY shared_libs    SYSTEM "shared_libs.xml">
 <!ENTITY what_glasgow_exts_does SYSTEM "what_glasgow_exts_does.gen.xml">
-<!ENTITY libraryBaseLocation    "../libraries/base-4.7.0.0">
-<!ENTITY libraryCabalLocation   "../libraries/Cabal-1.18.1.3">
-<!ENTITY libraryGhcPrimLocation "../libraries/ghc-prim-0.3.1.0">
+<!ENTITY libraryBaseLocation    "../libraries/base-4.8.2.0">
+<!ENTITY libraryCabalLocation   "../libraries/Cabal-1.22.5.0">
+<!ENTITY libraryGhcPrimLocation "../libraries/ghc-prim-0.4.0.0">
 <!ENTITY arw "-&gt;">
original のみに存在: users_guide
diff -urd 7.8.2-original/using.xml original/using.xml
--- 7.8.2-original/using.xml	2014-04-08 03:26:08.000000000 +0900
+++ original/using.xml	2016-04-09 21:36:11.394998369 +0900
@@ -246,6 +246,13 @@
       </varlistentry>
 
       <varlistentry>
+        <term><filename>.hspp</filename></term>
+        <listitem>
+          <para>A file created by the preprocessor.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><filename>.hi</filename></term>
         <listitem>
           <para>A Haskell interface file, probably
@@ -383,7 +390,7 @@
         <term>
           <cmdsynopsis>
             <command>ghc -E</command>
-            <command>ghc -c</command>
+            <command>ghc -C</command>
             <command>ghc -S</command>
             <command>ghc -c</command>
           </cmdsynopsis>
@@ -395,10 +402,7 @@
         <listitem>
           <para>This is the traditional batch-compiler mode, in which
           GHC can compile source files one at a time, or link objects
-          together into an executable.  This mode also applies if
-          there is no other mode flag specified on the command line,
-          in which case it means that the specified files should be
-          compiled and then linked to form a program. See <xref
+          together into an executable. See <xref
           linkend="options-order"/>.</para>
         </listitem>
       </varlistentry>
@@ -617,6 +621,11 @@
       given on the command line and GHC will include them when linking
       the executable.</para>
 
+      <para>For backward compatibility with existing make scripts, when
+      used in combination with <option>-c</option>, the linking phase
+      is omitted (same as <option>--make</option>
+      <option>-no-link</option>).</para>
+
       <para>Note that GHC can only follow dependencies if it has the
       source file available, so if your program includes a module for
       which there is no source file, even if you have an object and an
@@ -765,6 +774,10 @@
       option</primary></indexterm> runs just the pre-processing passes
       of the compiler, dumping the result in a file.</para>
 
+      <para>Note: The option <option>-C</option> is only available when
+      GHC is built in unregisterised mode. See <xref linkend="unreg"/>
+      for more details.</para>
+
       <sect3 id="overriding-suffixes">
         <title>Overriding the default behaviour for a file</title>
 
@@ -899,20 +912,38 @@
 ghci> :t f
 f :: forall a. a -> a
 </screen>
-         Using <option>-fprint-explicit-kinds</option> makes GHC print kind-foralls and kind applications
+However, regardless of the flag setting, the quantifiers are printed under these circumstances:
+<itemizedlist>
+<listitem><para>For nested <literal>foralls</literal>, e.g.
+<screen>
+ghci> :t GHC.ST.runST
+GHC.ST.runST :: (forall s. GHC.ST.ST s a) -> a
+</screen>
+</para></listitem>
+<listitem><para>If any of the quantified type variables has a kind
+that mentions a kind variable, e.g.
+<screen>
+ghci> :i Data.Type.Equality.sym
+Data.Type.Equality.sym ::
+  forall (k :: BOX) (a :: k) (b :: k).
+  (a Data.Type.Equality.:~: b) -> b Data.Type.Equality.:~: a
+        -- Defined in Data.Type.Equality
+</screen>
+</para></listitem>
+</itemizedlist>
+          </para>
+          <para>
+         Using <option>-fprint-explicit-kinds</option> makes GHC print kind arguments
          in types, which are normally suppressed.  This can be important when you are using kind polymorphism.
          For example:
 <screen>
 ghci> :set -XPolyKinds
 ghci> data T a = MkT
 ghci> :t MkT
-MkT :: T b
+MkT :: forall (k :: BOX) (a :: k). T a
 ghci> :set -fprint-explicit-foralls
 ghci> :t MkT
-MkT :: forall (b::k). T b
-ghci> :set -fprint-explicit-kinds
-ghci> :t MkT
-MkT :: forall (k::BOX) (b:k). T b
+MkT :: forall (k :: BOX) (a :: k). T k a
 </screen>
          </para>
         </listitem>
@@ -1003,7 +1034,6 @@
     program.  These are:
     <option>-fwarn-overlapping-patterns</option>,
     <option>-fwarn-warnings-deprecations</option>,
-    <option>-fwarn-amp</option>,
     <option>-fwarn-deprecated-flags</option>,
     <option>-fwarn-unrecognised-pragmas</option>,
     <option>-fwarn-pointless-pragmas</option>,
@@ -1016,8 +1046,10 @@
     <option>-fwarn-wrong-do-bind</option>,
     <option>-fwarn-unsupported-calling-conventions</option>,
     <option>-fwarn-dodgy-foreign-imports</option>,
-    <option>-fwarn-inline-rule-shadowing</option>, and
-    <option>-fwarn-unsupported-llvm-version</option>.
+    <option>-fwarn-inline-rule-shadowing</option>,
+    <option>-fwarn-unsupported-llvm-version</option>,
+    <option>-fwarn-context-quantification</option>, and
+    <option>-fwarn-tabs</option>.
     The following flags are simple ways to select standard
     &ldquo;packages&rdquo; of warnings:
     </para>
@@ -1029,12 +1061,12 @@
         <listitem>
           <indexterm><primary>-W option</primary></indexterm>
           <para>Provides the standard warnings plus
-          <option>-fwarn-incomplete-patterns</option>,
-          <option>-fwarn-dodgy-exports</option>,
-          <option>-fwarn-dodgy-imports</option>,
+          <option>-fwarn-unused-binds</option>,
           <option>-fwarn-unused-matches</option>,
-          <option>-fwarn-unused-imports</option>, and
-          <option>-fwarn-unused-binds</option>.</para>
+          <option>-fwarn-unused-imports</option>,
+          <option>-fwarn-incomplete-patterns</option>,
+          <option>-fwarn-dodgy-exports</option>, and
+          <option>-fwarn-dodgy-imports</option>.</para>
         </listitem>
       </varlistentry>
 
@@ -1046,14 +1078,15 @@
           suspicious code.  The warnings that are
           <emphasis>not</emphasis> enabled by <option>-Wall</option>
           are
-            <option>-fwarn-tabs</option>,
             <option>-fwarn-incomplete-uni-patterns</option>,
             <option>-fwarn-incomplete-record-updates</option>,
             <option>-fwarn-monomorphism-restriction</option>,
             <option>-fwarn-auto-orphans</option>,
             <option>-fwarn-implicit-prelude</option>,
             <option>-fwarn-missing-local-sigs</option>,
-            <option>-fwarn-missing-import-lists</option>.</para>
+            <option>-fwarn-missing-exported-sigs</option>,
+            <option>-fwarn-missing-import-lists</option> and
+            <option>-fwarn-identities</option>.</para>
         </listitem>
       </varlistentry>
 
@@ -1099,14 +1132,11 @@
           <indexterm><primary><option>-fwarn-typed-holes</option></primary>
           </indexterm>
           <indexterm><primary>warnings</primary></indexterm>
-            <para>When the compiler encounters an unbound local
-            variable prefixed with <literal>_</literal>, or encounters
-            the literal <literal>_</literal> on the right-hand side of
-            an expression, the error message for the unbound term
-            includes the type it needs to type check. It works
-            particularly well with <link
-            linkend="defer-type-errors">deferred type errors</link>.
-            See <xref linkend="typed-holes"/></para>
+          <para>
+              Determines whether the compiler reports typed holes warnings. Has
+              no effect unless typed holes errors are deferred until runtime.
+              See <xref linkend="typed-holes"/> and <xref linkend="defer-type-errors"/>
+            </para>
 
             <para>This warning is on by default.</para>
         </listitem>
@@ -1128,6 +1158,45 @@
       </varlistentry>
 
       <varlistentry>
+        <term><option>-fdefer-typed-holes</option>:</term>
+        <listitem>
+          <indexterm><primary><option>-fdefer-typed-holes</option></primary>
+          </indexterm>
+          <indexterm><primary>warnings</primary></indexterm>
+          <para>
+              Defer typed holes errors until runtime. This will turn the errors
+              produced by <link linked="typed-holes">typed holes</link> into
+              warnings. Using a value that depends on a typed hole produces a
+              runtime error, the same as <option>-fdefer-type-errors</option>
+              (which implies this option). See <xref linkend="typed-holes"/>
+              and <xref linkend="defer-type-errors"/>.
+          </para>
+          <para>
+              Implied by <option>-fdefer-type-errors</option>. See also
+              <option>-fwarn-typed-holes</option>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-fwarn-partial-type-signatures</option>:</term>
+        <listitem>
+          <indexterm><primary><option>-fwarn-partial-type-signatures</option></primary>
+          </indexterm>
+          <indexterm><primary>warnings</primary></indexterm>
+          <para>
+              Determines whether the compiler reports holes in partial type
+              signatures as warnings. Has no effect unless
+              <option>-XPartialTypeSignatures</option> is enabled, which
+              controls whether errors should be generated for holes in types
+              or not. See <xref linkend="partial-type-signatures"/>.
+            </para>
+
+            <para>This warning is on by default.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><option>-fhelpful-errors</option>:</term>
         <listitem>
           <indexterm><primary><option>-fhelpful-errors</option></primary>
@@ -1579,6 +1648,21 @@
       </varlistentry>
 
       <varlistentry>
+        <term><option>-fwarn-missing-exported-sigs</option>:</term>
+        <listitem>
+          <indexterm><primary><option>-fwarn-missing-exported-sigs</option></primary></indexterm>
+          <indexterm><primary>type signatures, missing</primary></indexterm>
+
+          <para>If you would like GHC to check that every exported top-level
+          function/value has a type signature, but not check unexported values, use the
+          <option>-fwarn-missing-exported-sigs</option> option.  This option
+          takes precedence over <option>-fwarn-missing-signatures</option>.
+          As part of the warning GHC also reports the inferred type.  The
+          option is off by default.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><option>-fwarn-missing-local-sigs</option>:</term>
         <listitem>
           <indexterm><primary><option>-fwarn-missing-local-sigs</option></primary></indexterm>
@@ -1672,8 +1756,6 @@
           <indexterm><primary>tabs, warning</primary></indexterm>
           <para>Have the compiler warn if there are tabs in your source
           file.</para>
-
-          <para>This warning is off by default.</para>
         </listitem>
       </varlistentry>
 
@@ -1713,21 +1795,80 @@
       </varlistentry>
 
       <varlistentry>
+        <term><option>-fwarn-unticked-promoted-constructors</option>:</term>
+        <listitem>
+          <indexterm><primary><option>-fwarn-unticked-promoted-constructors</option></primary></indexterm>
+          <indexterm><primary>promoted constructor, warning</primary></indexterm>
+          <para>Warn if a promoted data constructor is used without a tick preceding it's name.
+          </para>
+          <para>For example:
+          </para>
+<programlisting>
+data Nat = Succ Nat | Zero
+
+data Vec n s where
+  Nil  :: Vec Zero a
+  Cons :: a -> Vec n a -> Vec (Succ n) a
+</programlisting>
+            <para> Will raise two warnings because <function>Zero</function>
+            and <function>Succ</function> are not written as <function>'Zero</function> and
+            <function>'Succ</function>.
+            </para>
+            <para>This warning is enabled by default in <literal>-Wall</literal> mode.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><option>-fwarn-unused-binds</option>:</term>
         <listitem>
           <indexterm><primary><option>-fwarn-unused-binds</option></primary></indexterm>
           <indexterm><primary>unused binds, warning</primary></indexterm>
           <indexterm><primary>binds, unused</primary></indexterm>
           <para>Report any function definitions (and local bindings)
-          which are unused.  For top-level functions, the warning is
-          only given if the binding is not exported.</para>
-          <para>A definition is regarded as "used" if (a) it is exported, or (b) it is
-            mentioned in the right hand side of another definition that is used, or (c) the
-            function it defines begins with an underscore.  The last case provides a
-            way to suppress unused-binding warnings selectively.  </para>
-          <para> Notice that a variable
-            is reported as unused even if it appears in the right-hand side of another
-            unused binding. </para>
+          which are unused.  More precisely:
+
+          <itemizedlist>
+          <listitem><para>Warn if a binding brings into scope a variable that is not used,
+          except if the variable's name starts with an underscore.  The "starts-with-underscore"
+          condition provides a way to selectively disable the warning.
+        </para>
+          <para>
+          A variable is regarded as "used" if 
+          <itemizedlist>
+          <listitem><para>It is exported, or</para></listitem>
+          <listitem><para>It appears in the right hand side of a binding that binds at 
+                           least one used variable that is used</para></listitem>
+          </itemizedlist>
+          For example
+            <programlisting>
+module A (f) where
+f = let (p,q) = rhs1 in t p  -- Warning about unused q
+t = rhs3                     -- No warning: f is used, and hence so is t
+g = h x                      -- Warning: g unused
+h = rhs2                     -- Warning: h is only used in the right-hand side of another unused binding
+_w = True                    -- No warning: _w starts with an underscore
+            </programlisting>
+          </para></listitem>
+
+          <listitem><para>
+          Warn if a pattern binding binds no variables at all, unless it is a lone, possibly-banged, wild-card pattern.
+          For example:
+            <programlisting>
+Just _ = rhs3    -- Warning: unused pattern binding
+(_, _) = rhs4    -- Warning: unused pattern binding
+_  = rhs3        -- No warning: lone wild-card pattern
+!_ = rhs4        -- No warning: banged wild-card pattern; behaves like seq
+            </programlisting>
+          The motivation for allowing lone wild-card patterns is they
+          are not very different from <literal>_v = rhs3</literal>,
+          which elicits no warning; and they can be useful to add a type
+          constraint, e.g. <literal>_ = x::Int</literal>. A lone
+          banged wild-card pattern is is useful as an alternative 
+          (to <literal>seq</literal>) way to force evaluation.
+        </para>
+        </listitem>
+          </itemizedlist>
+          </para>
         </listitem>
       </varlistentry>
 
@@ -1790,6 +1931,27 @@
       </varlistentry>
 
       <varlistentry>
+        <term><option>-fwarn-context-quantification</option>:</term>
+        <listitem>
+          <indexterm><primary><option>-fwarn-context-quantification</option></primary></indexterm>
+          <indexterm><primary>implicit context quantification, warning</primary></indexterm>
+          <indexterm><primary>context, implicit quantification</primary></indexterm>
+
+          <para>Report if a variable is quantified only due to its presence
+          in a context (see <xref linkend="universal-quantification"/>). For example,
+            <programlisting>
+              type T a = Monad m => a -> f a
+            </programlisting>
+          It is recommended to write this polymorphic type as
+            <programlisting>
+              type T a = forall m. Monad m => a -> f a
+            </programlisting>
+          instead.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><option>-fwarn-wrong-do-bind</option>:</term>
         <listitem>
           <indexterm><primary><option>-fwarn-wrong-do-bind</option></primary></indexterm>
@@ -1814,6 +1976,16 @@
         </listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><option>-fwarn-inline-rule-shadowing</option>:</term>
+        <listitem>
+          <indexterm><primary><option>-fwarn-inline-rule-shadowing</option></primary></indexterm>
+          <para>Warn if a rewrite RULE might fail to fire because the function might be
+                inlined before the rule has a chance to fire.  See <xref linkend="rules-inline"/>.
+              </para>
+        </listitem>
+      </varlistentry>
+
     </variablelist>
 
     <para>If you're feeling really paranoid, the
@@ -1922,6 +2094,21 @@
             <option>-O</option>.</para>
           </listitem>
         </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-Odph</option>:
+            <indexterm><primary>-Odph</primary></indexterm>
+            <indexterm><primary>optimise</primary><secondary>DPH</secondary></indexterm>
+          </term>
+          <listitem>
+            <para>Enables all <option>-O2</option> optimisation, sets
+                  <option>-fmax-simplifier-iterations=20</option>
+                  and <option>-fsimplifier-phases=3</option>. Designed for use with
+                  <link linkend="dph">Data Parallel Haskell (DPH)</link>.</para>
+          </listitem>
+        </varlistentry>
+
       </variablelist>
 
       <para>We don't use a <option>-O*</option> flag for day-to-day
@@ -1942,40 +2129,16 @@
       <indexterm><primary>-fno-* options (GHC)</primary></indexterm>
 
       <para>These flags turn on and off individual optimisations.
-      They are normally set via the <option>-O</option> options
-      described above, and as such, you shouldn't need to set any of
-      them explicitly (indeed, doing so could lead to unexpected
-      results).  A flag <option>-fwombat</option> can be negated by 
-      saying <option>-fno-wombat</option>.  The flags below are off
-      by default, except where noted below.  See <xref linkend="options-f-compact"/> 
-      for a compact list.
+      Flags marked as <emphasis>Enabled by default</emphasis> are
+      enabled by <option>-O</option>, and as such you shouldn't
+      need to set any of them explicitly.  A flag <option>-fwombat</option>
+      can be negated by saying <option>-fno-wombat</option>.
+      See <xref linkend="options-f-compact"/> for a compact list.
      </para>
 
       <variablelist>
         <varlistentry>
           <term>
-            <option>-favoid-vect</option>
-            <indexterm><primary><option></option></primary></indexterm>
-          </term>
-          <listitem>
-            <para>Part of <link linkend="dph">Data Parallel Haskell
-            (DPH)</link>.</para>
-
-            <para><emphasis>Off by default.</emphasis> Enable the
-            <emphasis>vectorisation</emphasis> avoidance optimisation. This
-            optimisation only works when used in combination with the
-            <option>-fvectorise</option> transformation.</para>
-
-            <para>While vectorisation of code using DPH is often a big win, it
-            can also produce worse results for some kinds of code. This
-            optimisation modifies the vectorisation transformation to try to
-            determine if a function would be better of unvectorised and if
-            so, do just that.</para>
-          </listitem>
-        </varlistentry>
-
-        <varlistentry>
-          <term>
             <option>-fcase-merge</option>
             <indexterm><primary><option></option></primary></indexterm>
           </term>
@@ -2000,6 +2163,56 @@
 
         <varlistentry>
           <term>
+            <option>-fcall-arity</option>
+            <indexterm><primary><option>-fcall-arity</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para><emphasis>On by default.</emphasis>.
+            </para>
+          </listitem>
+        </varlistentry>
+
+         <varlistentry>
+          <term>
+            <option>-fcmm-elim-common-blocks</option>
+            <indexterm><primary><option>-felim-common-blocks</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para><emphasis>On by default.</emphasis>.  Enables the common block
+            elimination optimisation in the code generator. This optimisation
+            attempts to find identical Cmm blocks and eliminate the duplicates.
+            </para>
+          </listitem>
+        </varlistentry>
+
+         <varlistentry>
+          <term>
+            <option>-fcmm-sink</option>
+            <indexterm><primary><option>-fcmm-sink</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para><emphasis>On by default.</emphasis>.  Enables the sinking pass
+            in the code generator. This optimisation
+            attempts to find identical Cmm blocks and eliminate the duplicates
+            attempts to move variable bindings closer to their usage sites. It
+            also inlines simple expressions like literals or registers.
+            </para>
+          </listitem>
+        </varlistentry>
+
+         <varlistentry>
+          <term>
+            <option>-fcpr-off</option>
+            <indexterm><primary><option>-fcpr-Off</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Switch off CPR analysis in the demand analyser.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
             <option>-fcse</option>
             <indexterm><primary><option>-fcse</option></primary></indexterm>
           </term>
@@ -2025,12 +2238,25 @@
 
         <varlistentry>
           <term>
-            <option>-fdo-lambda-eta-expansion</option>
+            <option>-fdicts-strict</option>
             <indexterm><primary><option></option></primary></indexterm>
           </term>
           <listitem>
-            <para><emphasis>On by default.</emphasis>
-            Eta-expand let-bindings to increase their arity.
+            <para>Make dictionaries strict.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fdmd-tx-dict-sel</option>
+            <indexterm><primary><option>-fdmd-tx-dict-sel</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para><emphasis>On by default for <option>-O0</option>, <option>-O</option>,
+                  <option>-O2</option>.</emphasis>
+            </para>
+            <para>Use a special demand transformer for dictionary selectors.
             </para>
           </listitem>
         </varlistentry>
@@ -2050,6 +2276,18 @@
 
         <varlistentry>
           <term>
+            <option>-fdo-lambda-eta-expansion</option>
+            <indexterm><primary><option></option></primary></indexterm>
+          </term>
+          <listitem>
+            <para><emphasis>On by default.</emphasis>
+            Eta-expand let-bindings to increase their arity.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
             <option>-feager-blackholing</option>
             <indexterm><primary><option></option></primary></indexterm>
           </term>
@@ -2176,12 +2414,12 @@
             <indexterm><primary><option>-fignore-asserts</option></primary></indexterm>
           </term>
           <listitem>
-            <para>Causes GHC to ignore uses of the function
+            <para><emphasis>On by default.</emphasis>.
+            Causes GHC to ignore uses of the function
             <literal>Exception.assert</literal> in source code (in
             other words, rewriting <literal>Exception.assert p
             e</literal> to <literal>e</literal> (see <xref
-            linkend="assertions"/>).  This flag is turned on by
-            <option>-O</option>.
+            linkend="assertions"/>).
             </para>
           </listitem>
         </varlistentry>
@@ -2204,12 +2442,12 @@
             <indexterm><primary><option>-flate-dmd-anal</option></primary></indexterm>
           </term>
           <listitem>
-            <para><emphasis>Off by default.</emphasis>Run demand analysis
+            <para>Run demand analysis
             again, at the end of the simplification pipeline.  We found some opportunities
             for discovering strictness that were not visible earlier; and optimisations like
             <literal>-fspec-constr</literal> can create functions with unused arguments which
             are eliminated by late demand analysis.  Improvements are modest, but so is the
-            cost.  See notes on the <ulink href="http://ghc.haskell.org/trac/ghc/wiki/LateDmd">Trac wiki page</ulink>.
+            cost.  See notes on the <ulink url="http://ghc.haskell.org/trac/ghc/wiki/LateDmd">Trac wiki page</ulink>.
             </para>
             </listitem>
         </varlistentry>
@@ -2232,26 +2470,78 @@
 
         <varlistentry>
           <term>
-            <option>-fliberate-case-threshold=N</option>
+            <option>-fliberate-case-threshold=<replaceable>n</replaceable></option>
             <indexterm><primary><option>-fliberate-case-threshold</option></primary></indexterm>
           </term>
           <listitem>
-            <para>Set the size threshold for the liberate-case transformation.
+            <para>Set the size threshold for the liberate-case transformation. Default: 2000
             </para>
           </listitem>
         </varlistentry>
 
         <varlistentry>
           <term>
-            <option>-fmax-relevant-bindings=N</option>
+            <option>-floopification</option>
+            <indexterm><primary><option>-floopification</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para><emphasis>On by default.</emphasis>
+            </para>
+            <para>When this optimisation is enabled the code generator will turn
+                  all self-recursive saturated tail calls into local jumps rather
+                  than function calls.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fmax-inline-alloc-size=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fmax-inline-alloc-size</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Set the maximum size of inline array allocations to n bytes
+                 (default: 128). GHC will allocate non-pinned arrays of statically
+                 known size in the current nursery block if they're no bigger
+                 than n bytes, ignoring GC overheap. This value should be quite
+                 a bit smaller than the block size (typically: 4096).
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fmax-inline-memcpy-insn=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fmax-inline-memcpy-insn</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Inline memcpy calls if they would generate no more than n pseudo instructions (default: 32).
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fmax-inline-memset-insns=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fmax-inline-memset-insns</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Inline memset calls if they would generate no more than n pseudo instructions (default: 32).
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fmax-relevant-binds=<replaceable>n</replaceable></option>
             <indexterm><primary><option>-fmax-relevant-bindings</option></primary></indexterm>
           </term>
           <listitem>
             <para>The type checker sometimes displays a fragment of the type environment
                   in error messages, but only up to some maximum number, set by this flag.
-                  The default is 6.  Turning it off with <option>-fno-max-relevant-bindings</option> 
-                   gives an unlimited number. Syntactically top-level bindings are also 
-                   usually excluded (since they may be numerous), but 
+                  The default is 6.  Turning it off with <option>-fno-max-relevant-bindings</option>
+                   gives an unlimited number. Syntactically top-level bindings are also
+                   usually excluded (since they may be numerous), but
                    <option>-fno-max-relevant-bindings</option> includes them too.
             </para>
           </listitem>
@@ -2259,6 +2549,50 @@
 
         <varlistentry>
           <term>
+            <option>-fmax-simplifier-iterations=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fmax-simplifier-iterations</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Sets the maximal number of iterations for the simplifier. Defult: 4.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fmax-worker-args=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fmax-worker-args</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>If a worker has that many arguments, none will be unpacked anymore (default: 10)
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fno-opt-coercion</option>
+            <indexterm><primary><option>-fno-opt-coercion</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Turn off the coercion optimiser.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fno-pre-inlining</option>
+            <indexterm><primary><option>-fno-pre-inlining</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Turn off pre-inlining.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
             <option>-fno-state-hack</option>
             <indexterm><primary><option>-fno-state-hack</option></primary></indexterm>
           </term>
@@ -2326,11 +2660,11 @@
         <varlistentry>
           <term>
             <option>-fregs-graph</option>
-            <indexterm><primary><option></option></primary></indexterm>
+            <indexterm><primary><option>-fregs-graph</option></primary></indexterm>
           </term>
           <listitem>
-            <para><emphasis>Off by default, but enabled by -O2. Only applies in
-              combination with the native code generator.</emphasis>
+            <para><emphasis>Off by default due to a performance regression bug.
+            Only applies in combination with the native code generator.</emphasis>
             Use the graph colouring register allocator for register allocation
             in the native code generator. By default, GHC uses a simpler,
             faster linear register allocator. The downside being that the
@@ -2342,14 +2676,14 @@
         <varlistentry>
           <term>
             <option>-fregs-iterative</option>
-            <indexterm><primary><option></option></primary></indexterm>
+            <indexterm><primary><option>-fregs-iterative</option></primary></indexterm>
           </term>
           <listitem>
             <para><emphasis>Off by default, only applies in combination with
               the native code generator.</emphasis>
             Use the iterative coalescing graph colouring register allocator for
             register allocation in the native code generator. This is the same
-            register allocator as the <option>-freg-graph</option> one but also
+            register allocator as the <option>-fregs-graph</option> one but also
             enables iterative coalescing during register allocation.
             </para>
           </listitem>
@@ -2357,6 +2691,17 @@
 
         <varlistentry>
           <term>
+            <option>-fsimplifier-phases=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fsimplifier-phases</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Set the number of phases for the simplifier (default 2). Ignored with -O0.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
             <option>-fsimpl-tick-factor=<replaceable>n</replaceable></option>
             <indexterm><primary><option>-fsimpl-tick-factor</option></primary></indexterm>
           </term>
@@ -2385,77 +2730,6 @@
 
         <varlistentry>
           <term>
-            <option>-funfolding-creation-threshold=<replaceable>n</replaceable></option>:
-            <indexterm><primary><option>-funfolding-creation-threshold</option></primary></indexterm>
-            <indexterm><primary>inlining, controlling</primary></indexterm>
-            <indexterm><primary>unfolding, controlling</primary></indexterm>
-          </term>
-          <listitem>
-            <para>(Default: 45) Governs the maximum size that GHC will allow a
-            function unfolding to be. (An unfolding has a &ldquo;size&rdquo;
-            that reflects the cost in terms of &ldquo;code bloat&rdquo; of
-            expanding (aka inlining) that unfolding at a call site. A bigger
-            function would be assigned a bigger cost.)
-            </para>
-
-            <para>Consequences: (a) nothing larger than this will be inlined
-            (unless it has an INLINE pragma); (b) nothing larger than this
-            will be spewed into an interface file.
-            </para>
-
-            <para>Increasing this figure is more likely to result in longer
-            compile times than faster code. The
-            <option>-funfolding-use-threshold</option> is more useful.
-            </para>
-          </listitem>
-        </varlistentry>
-
-        <varlistentry>
-          <term>
-            <option>-funfolding-use-threshold=<replaceable>n</replaceable></option>
-            <indexterm><primary><option>-funfolding-use-threshold</option></primary></indexterm>
-            <indexterm><primary>inlining, controlling</primary></indexterm>
-            <indexterm><primary>unfolding, controlling</primary></indexterm>
-          </term>
-          <listitem>
-            <para>(Default: 8) This is the magic cut-off figure for unfolding
-            (aka inlining): below this size, a function definition will be
-            unfolded at the call-site, any bigger and it won't. The size
-            computed for a function depends on two things: the actual size of
-            the expression minus any discounts that
-            apply (see <option>-funfolding-con-discount</option>).
-            </para>
-
-            <para>The difference between this and
-            <option>-funfolding-creation-threshold</option> is that this one
-            determines if a function definition will be inlined <emphasis>at
-              a call site</emphasis>. The other option determines if a
-            function definition will be kept around at all for potential
-            inlining.
-            </para>
-          </listitem>
-        </varlistentry>
-
-        <varlistentry>
-          <term>
-            <option>-fvectorise</option>
-            <indexterm><primary><option></option></primary></indexterm>
-          </term>
-          <listitem>
-            <para>Part of <link linkend="dph">Data Parallel Haskell
-            (DPH)</link>.</para>
-
-            <para><emphasis>Off by default.</emphasis> Enable the
-            <emphasis>vectorisation</emphasis> optimisation transformation. This
-            optimisation transforms the nested data parallelism code of programs
-            using DPH into flat data parallelism. Flat data parallel programs
-            should have better load balancing, enable SIMD parallelism and
-            friendlier cache behaviour.</para>
-          </listitem>
-        </varlistentry>
-
-        <varlistentry>
-          <term>
             <option>-fspec-constr</option>
             <indexterm><primary><option>-fspec-constr</option></primary></indexterm>
           </term>
@@ -2538,6 +2812,30 @@
 
         <varlistentry>
           <term>
+            <option>-fspec-constr-count=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fspec-constr-count</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Set the maximum number of specialisations
+                  that will be created for any one function by the SpecConstr
+                  transformation (default: 3).
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fspec-constr-threshold=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fspec-constr-threshold</option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Set the size threshold for the SpecConstr transformation (default: 2000).
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
             <option>-fspecialise</option>
             <indexterm><primary><option>-fspecialise</option></primary></indexterm>
           </term>
@@ -2592,25 +2890,12 @@
 
         <varlistentry>
           <term>
-            <option>-funbox-strict-fields</option>:
-            <indexterm><primary><option>-funbox-strict-fields</option></primary></indexterm>
-            <indexterm><primary>strict constructor fields</primary></indexterm>
-            <indexterm><primary>constructor fields, strict</primary></indexterm>
+            <option>-fstrictness-before=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-fstrictness-before</option></primary></indexterm>
           </term>
           <listitem>
-            <para>This option causes all constructor fields which are marked
-            strict (i.e. &ldquo;!&rdquo;) to be unpacked if possible. It is
-            equivalent to adding an <literal>UNPACK</literal> pragma to every
-            strict constructor field (see <xref linkend="unpack-pragma"/>).
+            <para>Run an additional strictness analysis before simplifier phase n.
             </para>
-
-            <para>This option is a bit of a sledgehammer: it might sometimes
-            make things worse. Selectively unboxing fields by using
-            <literal>UNPACK</literal> pragmas might be better. An alternative
-            is to use <option>-funbox-strict-fields</option> to turn on
-            unboxing by default but disable it for certain constructor
-            fields using the <literal>NOUNPACK</literal> pragma (see
-            <xref linkend="nounpack-pragma"/>).</para>
           </listitem>
         </varlistentry>
 
@@ -2662,6 +2947,162 @@
           </listitem>
         </varlistentry>
 
+        <varlistentry>
+          <term>
+            <option>-funbox-strict-fields</option>:
+            <indexterm><primary><option>-funbox-strict-fields</option></primary></indexterm>
+            <indexterm><primary>strict constructor fields</primary></indexterm>
+            <indexterm><primary>constructor fields, strict</primary></indexterm>
+          </term>
+          <listitem>
+            <para>This option causes all constructor fields which are marked
+            strict (i.e. &ldquo;!&rdquo;) to be unpacked if possible. It is
+            equivalent to adding an <literal>UNPACK</literal> pragma to every
+            strict constructor field (see <xref linkend="unpack-pragma"/>).
+            </para>
+
+            <para>This option is a bit of a sledgehammer: it might sometimes
+            make things worse. Selectively unboxing fields by using
+            <literal>UNPACK</literal> pragmas might be better. An alternative
+            is to use <option>-funbox-strict-fields</option> to turn on
+            unboxing by default but disable it for certain constructor
+            fields using the <literal>NOUNPACK</literal> pragma (see
+            <xref linkend="nounpack-pragma"/>).</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-funfolding-creation-threshold=<replaceable>n</replaceable></option>:
+            <indexterm><primary><option>-funfolding-creation-threshold</option></primary></indexterm>
+            <indexterm><primary>inlining, controlling</primary></indexterm>
+            <indexterm><primary>unfolding, controlling</primary></indexterm>
+          </term>
+          <listitem>
+            <para>(Default: 750) Governs the maximum size that GHC will allow a
+            function unfolding to be. (An unfolding has a &ldquo;size&rdquo;
+            that reflects the cost in terms of &ldquo;code bloat&rdquo; of
+            expanding (aka inlining) that unfolding at a call site. A bigger
+            function would be assigned a bigger cost.)
+            </para>
+
+            <para>Consequences: (a) nothing larger than this will be inlined
+            (unless it has an INLINE pragma); (b) nothing larger than this
+            will be spewed into an interface file.
+            </para>
+
+            <para>Increasing this figure is more likely to result in longer
+            compile times than faster code. The
+            <option>-funfolding-use-threshold</option> is more useful.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-funfolding-dict-discount=<replaceable>n</replaceable></option>:
+            <indexterm><primary><option>-funfolding-dict-discount</option></primary></indexterm>
+            <indexterm><primary>inlining, controlling</primary></indexterm>
+            <indexterm><primary>unfolding, controlling</primary></indexterm>
+          </term>
+          <listitem>
+            <para>Default: 30
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-funfolding-fun-discount=<replaceable>n</replaceable></option>:
+            <indexterm><primary><option>-funfolding-fun-discount</option></primary></indexterm>
+            <indexterm><primary>inlining, controlling</primary></indexterm>
+            <indexterm><primary>unfolding, controlling</primary></indexterm>
+          </term>
+          <listitem>
+            <para>Default: 60
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-funfolding-keeness-factor=<replaceable>n</replaceable></option>:
+            <indexterm><primary><option>-funfolding-keeness-factor</option></primary></indexterm>
+            <indexterm><primary>inlining, controlling</primary></indexterm>
+            <indexterm><primary>unfolding, controlling</primary></indexterm>
+          </term>
+          <listitem>
+            <para>Default: 1.5
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-funfolding-use-threshold=<replaceable>n</replaceable></option>
+            <indexterm><primary><option>-funfolding-use-threshold</option></primary></indexterm>
+            <indexterm><primary>inlining, controlling</primary></indexterm>
+            <indexterm><primary>unfolding, controlling</primary></indexterm>
+          </term>
+          <listitem>
+            <para>(Default: 60) This is the magic cut-off figure for unfolding
+            (aka inlining): below this size, a function definition will be
+            unfolded at the call-site, any bigger and it won't. The size
+            computed for a function depends on two things: the actual size of
+            the expression minus any discounts that apply depending on the
+            context into which the expression is to be inlined.
+            </para>
+
+            <para>The difference between this and
+            <option>-funfolding-creation-threshold</option> is that this one
+            determines if a function definition will be inlined <emphasis>at
+              a call site</emphasis>. The other option determines if a
+            function definition will be kept around at all for potential
+            inlining.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fvectorisation-avoidance</option>
+            <indexterm><primary><option></option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Part of <link linkend="dph">Data Parallel Haskell
+            (DPH)</link>.</para>
+
+            <para><emphasis>On by default.</emphasis> Enable the
+            <emphasis>vectorisation</emphasis> avoidance optimisation. This
+            optimisation only works when used in combination with the
+            <option>-fvectorise</option> transformation.</para>
+
+            <para>While vectorisation of code using DPH is often a big win, it
+            can also produce worse results for some kinds of code. This
+            optimisation modifies the vectorisation transformation to try to
+            determine if a function would be better of unvectorised and if
+            so, do just that.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <option>-fvectorise</option>
+            <indexterm><primary><option></option></primary></indexterm>
+          </term>
+          <listitem>
+            <para>Part of <link linkend="dph">Data Parallel Haskell
+            (DPH)</link>.</para>
+
+            <para><emphasis>Off by default.</emphasis> Enable the
+            <emphasis>vectorisation</emphasis> optimisation transformation. This
+            optimisation transforms the nested data parallelism code of programs
+            using DPH into flat data parallelism. Flat data parallel programs
+            should have better load balancing, enable SIMD parallelism and
+            friendlier cache behaviour.</para>
+          </listitem>
+        </varlistentry>
+
       </variablelist>
 
     </sect2>
@@ -2819,13 +3260,29 @@
           <listitem>
             <para><indexterm><primary><option>-N<replaceable>x</replaceable></option></primary><secondary>RTS option</secondary></indexterm>
               Use <replaceable>x</replaceable> simultaneous threads when
-              running the program.  Normally <replaceable>x</replaceable>
-              should be chosen to match the number of CPU cores on the
-              machine<footnote><para>Whether hyperthreading cores should be counted or not is an
-              open question; please feel free to experiment and let us know what
-                  results you find.</para></footnote>.  For example,
-              on a dual-core machine we would probably use
-              <literal>+RTS -N2 -RTS</literal>.</para>
+              running the program.</para>
+
+              <para>The runtime manages a set of virtual processors,
+              which we call <emphasis>capabilities</emphasis>, the
+              number of which is determined by the <option>-N</option>
+              option.  Each capability can run one Haskell thread at a
+              time, so the number of capabilities is equal to the
+              number of Haskell threads that can run physically in
+              parallel.  A capability is animated by one or more OS
+              threads; the runtime manages a pool of OS threads for
+              each capability, so that if a Haskell thread makes a
+              foreign call (see <xref linkend="ffi-threads" />)
+              another OS thread can take over that capability.
+              </para>
+
+              <para>Normally <replaceable>x</replaceable> should be
+              chosen to match the number of CPU cores on the
+              machine<footnote><para>Whether hyperthreading cores
+              should be counted or not is an open question; please
+              feel free to experiment and let us know what results you
+              find.</para></footnote>.  For example, on a dual-core
+              machine we would probably use <literal>+RTS -N2
+              -RTS</literal>.</para>
 
             <para>Omitting <replaceable>x</replaceable>,
               i.e. <literal>+RTS -N -RTS</literal>, lets the runtime
@@ -2842,10 +3299,11 @@
               <xref linkend="rts-options-gc" />).</para>
 
             <para>The current value of the <option>-N</option> option
-              is available to the Haskell program
-              via <literal>Control.Concurrent.getNumCapabilities</literal>, and
-              it may be changed while the program is running by
-              calling <literal>Control.Concurrent.setNumCapabilities</literal>.</para>
+            is available to the Haskell program via
+            <literal>Control.Concurrent.getNumCapabilities</literal>,
+            and it may be changed while the program is running by
+            calling
+            <literal>Control.Concurrent.setNumCapabilities</literal>.</para>
           </listitem>
         </varlistentry>
       </variablelist>
@@ -2860,9 +3318,18 @@
           option</secondary></indexterm>
           <listitem>
             <para>Use the OS's affinity facilities to try to pin OS
-              threads to CPU cores.  This is an experimental feature,
-              and may or may not be useful.  Please let us know
-              whether it helps for you!</para>
+            threads to CPU cores.</para>
+
+            <para>When this option is enabled, the OS threads for a
+            capability <emphasis>i</emphasis> are bound to the CPU
+            core <emphasis>i</emphasis> using the API provided by the
+            OS for setting thread affinity.  e.g. on Linux
+            GHC uses <literal>sched_setaffinity()</literal>.</para>
+
+            <para>Depending on your workload and the other activity on
+            the machine, this may or may not result in a performance
+            improvement.  We recommend trying it out and measuring the
+            difference.</para>
           </listitem>
         </varlistentry>
         <varlistentry>
@@ -2967,44 +3434,6 @@
   </sect1>
 
 &runtime;
-
-<sect1 id="ext-core">
-  <title>Generating and compiling External Core Files</title>
-
-  <indexterm><primary>intermediate code generation</primary></indexterm>
-
-  <para>GHC can dump its optimized intermediate code (said to be in &ldquo;Core&rdquo; format)
-  to a file as a side-effect of compilation. Non-GHC back-end tools can read and process Core files; these files have the suffix
-  <filename>.hcr</filename>. The Core format is described in <ulink url="../../core.pdf">
-  <citetitle>An External Representation for the GHC Core Language</citetitle></ulink>,
-  and sample tools
-  for manipulating Core files (in Haskell) are available in the
-  <ulink url="http://hackage.haskell.org/package/extcore">extcore package on Hackage</ulink>.  Note that the format of <literal>.hcr</literal>
-  files is <emphasis>different</emphasis> from the Core output format that GHC generates
-  for debugging purposes (<xref linkend="options-debugging"/>), though the two formats appear somewhat similar.</para>
-
-  <para>The Core format natively supports notes which you can add to
-  your source code using the <literal>CORE</literal> pragma (see <xref
-  linkend="pragmas"/>).</para>
-
-    <variablelist>
-
-        <varlistentry>
-          <term>
-            <option>-fext-core</option>
-            <indexterm><primary><option>-fext-core</option></primary></indexterm>
-          </term>
-          <listitem>
-            <para>Generate <literal>.hcr</literal> files.</para>
-          </listitem>
-        </varlistentry>
-
-    </variablelist>
-
-<para>Currently (as of version 6.8.2), GHC does not have the ability to read in External Core files as source. If you would like GHC to have this ability, please <ulink url="http://ghc.haskell.org/trac/ghc/wiki/MailingListsAndIRC">make your wishes known to the GHC Team</ulink>.</para>
-
-</sect1>
-
 &debug;
 &flags;
 
diff -urd 7.8.2-original/what_glasgow_exts_does.gen.xml original/what_glasgow_exts_does.gen.xml
--- 7.8.2-original/what_glasgow_exts_does.gen.xml	2014-06-27 09:59:33.000000000 +0900
+++ original/what_glasgow_exts_does.gen.xml	2016-04-09 21:36:11.395998334 +0900
@@ -1,31 +1,31 @@
-<option>-XForeignFunctionInterface</option>,
-<option>-XUnliftedFFITypes</option>,
-<option>-XImplicitParams</option>,
-<option>-XScopedTypeVariables</option>,
-<option>-XUnboxedTuples</option>,
-<option>-XTypeSynonymInstances</option>,
-<option>-XStandaloneDeriving</option>,
+<option>-XConstrainedClassMethods</option>,
 <option>-XDeriveDataTypeable</option>,
-<option>-XDeriveFunctor</option>,
 <option>-XDeriveFoldable</option>,
-<option>-XDeriveTraversable</option>,
+<option>-XDeriveFunctor</option>,
 <option>-XDeriveGeneric</option>,
+<option>-XDeriveTraversable</option>,
+<option>-XEmptyDataDecls</option>,
+<option>-XExistentialQuantification</option>,
+<option>-XExplicitNamespaces</option>,
 <option>-XFlexibleContexts</option>,
 <option>-XFlexibleInstances</option>,
-<option>-XConstrainedClassMethods</option>,
-<option>-XMultiParamTypeClasses</option>,
+<option>-XForeignFunctionInterface</option>,
 <option>-XFunctionalDependencies</option>,
+<option>-XGeneralizedNewtypeDeriving</option>,
+<option>-XImplicitParams</option>,
+<option>-XKindSignatures</option>,
+<option>-XLiberalTypeSynonyms</option>,
 <option>-XMagicHash</option>,
-<option>-XExistentialQuantification</option>,
-<option>-XUnicodeSyntax</option>,
-<option>-XPostfixOperators</option>,
+<option>-XMultiParamTypeClasses</option>,
+<option>-XParallelListComp</option>,
 <option>-XPatternGuards</option>,
-<option>-XLiberalTypeSynonyms</option>,
+<option>-XPostfixOperators</option>,
 <option>-XRankNTypes</option>,
-<option>-XTypeOperators</option>,
-<option>-XExplicitNamespaces</option>,
 <option>-XRecursiveDo</option>,
-<option>-XParallelListComp</option>,
-<option>-XEmptyDataDecls</option>,
-<option>-XKindSignatures</option>,
-<option>-XGeneralizedNewtypeDeriving</option>.
+<option>-XScopedTypeVariables</option>,
+<option>-XStandaloneDeriving</option>,
+<option>-XTypeOperators</option>,
+<option>-XTypeSynonymInstances</option>,
+<option>-XUnboxedTuples</option>,
+<option>-XUnicodeSyntax</option>,
+<option>-XUnliftedFFITypes</option>.