X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fglasgow_exts.xml;h=a431dd648cf353a888cdc399907acde9acc4a202;hb=0bff4d75254dabb2c002eace2252a4480bf8474e;hp=393cbf50ac297252e7f2cc1cc0b71781a1d2f3ea;hpb=9bcd95bad83ee937c178970e8b729732e680fe1e;p=ghc-hetmet.git

diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index 393cbf5..a431dd6 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -1232,7 +1232,7 @@ it is not clear which of the two types is intended.
 </para>
 <para>
 Haskell 98 regards all four as ambiguous, but with the
-<option>-fdisambiguate-record-fields</option> flag, GHC will accept
+<option>-XDisambiguateRecordFields</option> flag, GHC will accept
 the former two.  The rules are precisely the same as those for instance
 declarations in Haskell 98, where the method names on the left-hand side 
 of the method bindings in an instance declaration refer unambiguously
@@ -2002,9 +2002,9 @@ of the data constructor.  For GADTs, the field may mention only types
 that appear as a simple type-variable argument in the constructor's result
 type</emphasis>.  For example:
 <programlisting>
-data T a where { T1 { f1::a, f2::(a,b) } :: T a }    -- b is existential
-upd1 t x = t { f1=x }   -- OK:   upd1 :: T a -> b -> T b
-upd2 t x = t { f2=x }   -- BAD   (f2's type mentions b, which is
+data T a b where { T1 { f1::a, f2::b, f3::(b,c) } :: T a b } -- c is existential
+upd1 t x = t { f1=x }   -- OK:   upd1 :: T a b -> a' -> T a' b
+upd2 t x = t { f3=x }   -- BAD   (f3's type mentions c, which is
                         --        existentially quantified)
 
 data G a b where { G1 { g1::a, g2::c } :: G a [c] }
@@ -3860,37 +3860,71 @@ data instance GMap (Either a b) v = GMapEither (GMap a v) (GMap b v)
       can be any number.
     </para>
     <para>
-      Data and newtype instance declarations are only legit when an
-      appropriate family declaration is in scope - just like class instances
-      require the class declaration to be visible.  Moreover, each instance
+      Data and newtype instance declarations are only permitted when an
+      appropriate family declaration is in scope - just as a class instance declaratoin
+      requires the class declaration to be visible.  Moreover, each instance
       declaration has to conform to the kind determined by its family
       declaration.  This implies that the number of parameters of an instance
       declaration matches the arity determined by the kind of the family.
-      Although, all data families are declared with
-      the <literal>data</literal> keyword, instances can be
-      either <literal>data</literal> or <literal>newtype</literal>s, or a mix
-      of both. 
     </para>
     <para>
+      A data family instance declaration can use the full exprssiveness of
+      ordinary <literal>data</literal> or <literal>newtype</literal> declarations:
+      <itemizedlist>
+      <listitem><para> Although, a data family is <emphasis>introduced</emphasis> with
+      the keyword "<literal>data</literal>", a data family <emphasis>instance</emphasis> can 
+      use either <literal>data</literal> or <literal>newtype</literal>. For example:
+<programlisting>
+data family T a
+data    instance T Int  = T1 Int | T2 Bool
+newtype instance T Char = TC Bool
+</programlisting>
+      </para></listitem>
+      <listitem><para> A <literal>data instance</literal> can use GADT syntax for the data constructors,
+      and indeed can define a GADT.  For example:
+<programlisting>
+data family G a b
+data instance G [a] b where
+   G1 :: c -> G [Int] b
+   G2 :: G [a] Bool
+</programlisting>
+      </para></listitem>
+      <listitem><para> You can use a <literal>deriving</literal> clause on a
+      <literal>data instance</literal> or <literal>newtype instance</literal>
+      declaration.
+      </para></listitem>
+      </itemizedlist>
+    </para>
+
+    <para>
       Even if type families are defined as toplevel declarations, functions
-      that perform different computations for different family instances still
+      that perform different computations for different family instances may still
       need to be defined as methods of type classes.  In particular, the
       following is not possible: 
 <programlisting>
 data family T a
 data instance T Int  = A
 data instance T Char = B
-nonsence :: T a -> Int
-nonsence A = 1             -- WRONG: These two equations together...
-nonsence B = 2             -- ...will produce a type error.
+foo :: T a -> Int
+foo A = 1             -- WRONG: These two equations together...
+foo B = 2             -- ...will produce a type error.
+</programlisting>
+Instead, you would have to write <literal>foo</literal> as a class operation, thus:
+<programlisting>
+class C a where 
+  foo :: T a -> Int
+instance Foo Int where
+  foo A = 1
+instance Foo Char where
+  foo B = 2
 </programlisting>
-      Given the functionality provided by GADTs (Generalised Algebraic Data
+      (Given the functionality provided by GADTs (Generalised Algebraic Data
       Types), it might seem as if a definition, such as the above, should be
       feasible.  However, type families are - in contrast to GADTs - are
       <emphasis>open;</emphasis> i.e., new instances can always be added,
       possibly in other 
       modules.  Supporting pattern matching across different data instances
-      would require a form of extensible case construct. 
+      would require a form of extensible case construct.)
     </para>
 
     <sect4 id="assoc-data-inst">
@@ -5994,7 +6028,7 @@ main = do { print $ eval [$expr|1 + 2|]
 module Expr where
 
 import qualified Language.Haskell.TH as TH
-import Language.Haskell.TH.Quasi
+import Language.Haskell.TH.Quote
 
 data Expr  =  IntExpr Integer
            |  AntiIntExpr String