Commit 9c2dfd97 authored by daniel.is.fischer's avatar daniel.is.fischer Committed by Simon Marlow

glasgow_exts.xml typos and whitespace

parent 3659b059
......@@ -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>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment