glasgow_exts.xml typos and whitespace

docs/users_guide/glasgow_exts.xml

@@ -425,7 +425,7 @@ Indeed, the bindings can even be recursive.
 	postfix modifier to identifiers.  Thus, "x#" is a valid variable, and "T#" is
 	a valid type constructor or data constructor.</para>
 
-      <para>The hash sign does not change sematics at all.  We tend to use variable
+      <para>The hash sign does not change semantics at all.  We tend to use variable
 	names ending in "&num;" for unboxed values or types (e.g. <literal>Int&num;</literal>),
 	but there is no requirement to do so; they are just plain ordinary variables.
 	Nor does the <option>-XMagicHash</option> extension bring anything into scope.
@@ -1208,10 +1208,10 @@ output = [ x
     <indexterm><primary>monad comprehensions</primary></indexterm>
 
     <para>
-        Monad comprehesions generalise the list comprehension notation,
+        Monad comprehensions generalise the list comprehension notation,
         including parallel comprehensions
         (<xref linkend="parallel-list-comprehensions"/>) and
-        transform comprenensions (<xref linkend="generalised-list-comprehensions"/>) 
+        transform comprehensions (<xref linkend="generalised-list-comprehensions"/>)
         to work for any monad.
     </para>
 
@@ -1639,7 +1639,7 @@ records from different modules that use the same field name.
 Some details:
 <itemizedlist>
 <listitem><para>
-Field disambiguation can be combined with punning (see <xref linkend="record-puns"/>). For exampe:
+Field disambiguation can be combined with punning (see <xref linkend="record-puns"/>). For example:
 <programlisting>
 module Foo where
   import M
@@ -1649,8 +1649,8 @@ module Foo where
 </para></listitem>
 
 <listitem><para>
-With <option>-XDisambiguateRecordFields</option> you can use <emphasis>unqualifed</emphasis>
-field names even if the correponding selector is only in scope <emphasis>qualified</emphasis>
+With <option>-XDisambiguateRecordFields</option> you can use <emphasis>unqualified</emphasis>
+field names even if the corresponding selector is only in scope <emphasis>qualified</emphasis>
 For example, assuming the same module <literal>M</literal> as in our earlier example, this is legal:
 <programlisting>
 module Foo where
@@ -1658,7 +1658,7 @@ module Foo where
 
   ok4 (M.MkS { x = n }) = n+1   -- Unambiguous
 </programlisting>
-Since the constructore <literal>MkS</literal> is only in scope qualified, you must
+Since the constructor <literal>MkS</literal> is only in scope qualified, you must
 name it <literal>M.MkS</literal>, but the field <literal>x</literal> does not need
 to be qualified even though <literal>M.x</literal> is in scope but <literal>x</literal>
 is not.  (In effect, it is qualified by the constructor.)
@@ -3206,7 +3206,7 @@ Scrap More Boilerplate: Reflection, Zips, and Generalised Casts
 (Section 7.4 of the paper describes the multiple <literal>Typeable</literal> classes that
 are used, and only <literal>Typeable1</literal> up to
 <literal>Typeable7</literal> are provided in the library.)
-In other cases, there is nothing to stop the programmer writing a <literal>TypableX</literal>
+In other cases, there is nothing to stop the programmer writing a <literal>TypeableX</literal>
 class, whose kind suits that of the data type constructor, and
 then writing the data type instance by hand.
 </para>
@@ -4537,14 +4537,14 @@ data instance GMap (Either a b) v = GMapEither (GMap a v) (GMap b v)
     </para>
     <para>
       Data and newtype instance declarations are only permitted when an
-      appropriate family declaration is in scope - just as a class instance declaratoin
+      appropriate family declaration is in scope - just as a class instance declaration
       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.
     </para>
     <para>
-      A data family instance declaration can use the full exprssiveness of
+      A data family instance declaration can use the full expressiveness of
       ordinary <literal>data</literal> or <literal>newtype</literal> declarations:
       <itemizedlist>
       <listitem><para> Although, a data family is <emphasis>introduced</emphasis> with
@@ -7846,7 +7846,7 @@ there really isn't any point in inlining <literal>key_function</literal> to get
 map (\x -> <replaceable>body</replaceable>) xs
 </programlisting>
 In general, GHC only inlines the function if there is some reason (no matter
-how slight) to supose that it is useful to do so.
+how slight) to suppose that it is useful to do so.
 </para></listitem>
 
 <listitem><para>
@@ -7890,7 +7890,7 @@ away.
 So <emphasis>GHC guarantees to inline precisely the code that you wrote</emphasis>, no more
 and no less.  It does this by capturing a copy of the definition of the function to use
 for inlining (we call this the "inline-RHS"), which it leaves untouched,
-while optimising the ordinarly RHS as usual.  For externally-visible functions
+while optimising the ordinarily RHS as usual.  For externally-visible functions
 the inline-RHS (not the optimised RHS) is recorded in the interface file.
 </para></listitem>
 <listitem><para>
@@ -8282,7 +8282,7 @@ on an ordinarily-recursive function.</para>
 Generally, you can only give a <literal>SPECIALIZE</literal> pragma
 for a function defined in the same module.
 However if a function <literal>f</literal> is given an <literal>INLINABLE</literal>
-pragma at its definition site, then it can subequently be specialised by
+pragma at its definition site, then it can subsequently be specialised by
 importing modules (see <xref linkend="inlinable-pragma"/>).
 For example
 <programlisting>
@@ -8333,7 +8333,7 @@ pragma can be useful.
 </para>
 </sect3>
 
-<sect3><title>Obselete SPECIALIZE syntax</title>
+<sect3><title>Obsolete SPECIALIZE syntax</title>
 
       <para>Note: In earlier versions of GHC, it was possible to provide your own
       specialised function for a given type:
@@ -8761,12 +8761,12 @@ when this is a good idea, so we provide the CONLIKE pragma to declare it, thus:
 {-# INLINE[1] CONLIKE f #-}
 f x = <replaceable>blah</replaceable>
 </programlisting>
-CONLIKE is a modifier to an INLINE or NOINLINE pragam.  It specifies that an application
+CONLIKE is a modifier to an INLINE or NOINLINE pragma.  It specifies that an application
 of f to one argument (in general, the number of arguments to the left of the '=' sign)
 should be considered cheap enough to duplicate, if such a duplication would make rule
 fire.  (The name "CONLIKE" is short for "constructor-like", because constructors certainly
 have such a property.)
-The CONLIKE pragam is a modifier to INLINE/NOINLINE because it really only makes sense to match 
+The CONLIKE pragma is a modifier to INLINE/NOINLINE because it really only makes sense to match
 <literal>f</literal> on the LHS of a rule if you are sure that <literal>f</literal> is
 not going to be inlined before the rule has a chance to fire.
 </para>
@@ -9212,7 +9212,7 @@ or the original paper:
 <itemizedlist>
 <listitem>
 <para>
-José Pedro Magalhães, Atze Dijkstra, Johan Jeuring, and Andres Löh.
+Jos� Pedro Magalh�es, Atze Dijkstra, Johan Jeuring, and Andres L�h.
 <ulink url="http://dreixel.net/research/pdf/gdmh.pdf">
   A generic deriving mechanism for Haskell</ulink>.
 <citetitle>Proceedings of the third ACM Haskell symposium on Haskell</citetitle>