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

glasgow_exts.xml typos and whitespace

parent 3659b059
......@@ -44,8 +44,8 @@ documentation</ulink> describes all the libraries that come with GHC.
<para>Language options can be controlled in two ways:
<itemizedlist>
<listitem><para>Every language option can switched on by a command-line flag "<option>-X...</option>"
(e.g. <option>-XTemplateHaskell</option>), and switched off by the flag "<option>-XNo...</option>";
<listitem><para>Every language option can switched on by a command-line flag "<option>-X...</option>"
(e.g. <option>-XTemplateHaskell</option>), and switched off by the flag "<option>-XNo...</option>";
(e.g. <option>-XNoTemplateHaskell</option>).</para></listitem>
<listitem><para>
Language options recognised by Cabal can also be enabled using the <literal>LANGUAGE</literal> pragma,
......@@ -55,11 +55,11 @@ documentation</ulink> describes all the libraries that come with GHC.
<para>The flag <option>-fglasgow-exts</option>
<indexterm><primary><option>-fglasgow-exts</option></primary></indexterm>
is equivalent to enabling the following extensions:
is equivalent to enabling the following extensions:
&what_glasgow_exts_does;
Enabling these options is the <emphasis>only</emphasis>
Enabling these options is the <emphasis>only</emphasis>
effect of <option>-fglasgow-exts</option>.
We are trying to move away from this portmanteau flag,
We are trying to move away from this portmanteau flag,
and towards enabling features individually.</para>
</sect1>
......@@ -77,8 +77,8 @@ While you really can use this stuff to write fast code,
unboxed version in any case. And if it isn't, we'd like to know
about it.</para>
<para>All these primitive data types and operations are exported by the
library <literal>GHC.Prim</literal>, for which there is
<para>All these primitive data types and operations are exported by the
library <literal>GHC.Prim</literal>, for which there is
<ulink url="&libraryGhcPrimLocation;/GHC-Prim.html">detailed online documentation</ulink>.
(This documentation is generated from the file <filename>compiler/prelude/primops.txt.pp</filename>.)
</para>
......@@ -89,10 +89,10 @@ into scope. Many of them have names ending in "&num;", and to mention such
names you need the <option>-XMagicHash</option> extension (<xref linkend="magic-hash"/>).
</para>
<para>The primops make extensive use of <link linkend="glasgow-unboxed">unboxed types</link>
<para>The primops make extensive use of <link linkend="glasgow-unboxed">unboxed types</link>
and <link linkend="unboxed-tuples">unboxed tuples</link>, which
we briefly summarise here. </para>
<sect2 id="glasgow-unboxed">
<title>Unboxed types
</title>
......@@ -124,7 +124,7 @@ know and love&mdash;usually one instruction.
Primitive (unboxed) types cannot be defined in Haskell, and are
therefore built into the language and compiler. Primitive types are
always unlifted; that is, a value of a primitive type cannot be
bottom. We use the convention (but it is only a convention)
bottom. We use the convention (but it is only a convention)
that primitive types, values, and
operations have a <literal>&num;</literal> suffix (see <xref linkend="magic-hash"/>).
For some primitive types we have special syntax for literals, also
......@@ -283,7 +283,7 @@ You can have an unboxed tuple in a pattern binding, thus
f x = let (# p,q #) = h x in ..body..
</programlisting>
If the types of <literal>p</literal> and <literal>q</literal> are not unboxed,
the resulting binding is lazy like any other Haskell pattern binding. The
the resulting binding is lazy like any other Haskell pattern binding. The
above example desugars like this:
<programlisting>
f x = let t = case h x o f{ (# p,q #) -> (p,q)
......@@ -302,7 +302,7 @@ Indeed, the bindings can even be recursive.
<sect1 id="syntax-extns">
<title>Syntactic extensions</title>
<sect2 id="unicode-syntax">
<title>Unicode syntax</title>
<para>The language
......@@ -425,17 +425,17 @@ Indeed, the bindings can even be recursive.
postfix modifier to identifiers. Thus, "x&num;" is a valid variable, and "T&num;" is
a valid type constructor or data constructor.</para>
<para>The hash sign does not change sematics at all. We tend to use variable
names ending in "&num;" for unboxed values or types (e.g. <literal>Int&num;</literal>),
<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.
For example, to bring <literal>Int&num;</literal> into scope you must
import <literal>GHC.Prim</literal> (see <xref linkend="primitives"/>);
For example, to bring <literal>Int&num;</literal> into scope you must
import <literal>GHC.Prim</literal> (see <xref linkend="primitives"/>);
the <option>-XMagicHash</option> extension
then allows you to <emphasis>refer</emphasis> to the <literal>Int&num;</literal>
that is now in scope.</para>
<para> The <option>-XMagicHash</option> also enables some new forms of literals (see <xref linkend="glasgow-unboxed"/>):
<itemizedlist>
<itemizedlist>
<listitem><para> <literal>'x'&num;</literal> has type <literal>Char&num;</literal></para> </listitem>
<listitem><para> <literal>&quot;foo&quot;&num;</literal> has type <literal>Addr&num;</literal></para> </listitem>
<listitem><para> <literal>3&num;</literal> has type <literal>Int&num;</literal>. In general,
......@@ -530,7 +530,7 @@ where
</programlisting>
<para>
The auxiliary functions are
The auxiliary functions are
</para>
<programlisting>
......@@ -575,10 +575,10 @@ This is a bit shorter, but hardly better. Of course, we can rewrite any set
of pattern-matching, guarded equations as case expressions; that is
precisely what the compiler does when compiling equations! The reason that
Haskell provides guarded equations is because they allow us to write down
the cases we want to consider, one at a time, independently of each other.
the cases we want to consider, one at a time, independently of each other.
This structure is hidden in the case version. Two of the right-hand sides
are really the same (<function>fail</function>), and the whole expression
tends to become more and more indented.
tends to become more and more indented.
</para>
<para>
......@@ -594,9 +594,9 @@ clunky env var1 var2
</programlisting>
<para>
The semantics should be clear enough. The qualifiers are matched in order.
The semantics should be clear enough. The qualifiers are matched in order.
For a <literal>&lt;-</literal> qualifier, which I call a pattern guard, the
right hand side is evaluated and matched against the pattern on the left.
right hand side is evaluated and matched against the pattern on the left.
If the match fails then the whole guard fails and the next equation is
tried. If it succeeds, then the appropriate binding takes place, and the
next qualifier is matched, in the augmented environment. Unlike list
......@@ -646,7 +646,7 @@ language as follows:
<programlisting>
type Typ
data TypView = Unit
| Arrow Typ Typ
......@@ -658,7 +658,7 @@ view :: Type -> TypeView
The representation of Typ is held abstract, permitting implementations
to use a fancy representation (e.g., hash-consing to manage sharing).
Without view patterns, using this signature a little inconvenient:
Without view patterns, using this signature a little inconvenient:
<programlisting>
size :: Typ -> Integer
size t = case view t of
......@@ -673,7 +673,7 @@ against <literal>t</literal> is buried deep inside another pattern.
<para>
View patterns permit calling the view function inside the pattern and
matching against the result:
matching against the result:
<programlisting>
size (view -> Unit) = 1
size (view -> Arrow t1 t2) = size t1 + size t2
......@@ -716,7 +716,7 @@ clunky env (lookup env -> Just val1) (lookup env -> Just val2) = val1 + val2
</para>
<para>
More precisely, the scoping rules are:
More precisely, the scoping rules are:
<itemizedlist>
<listitem>
<para>
......@@ -734,7 +734,7 @@ example :: (String -> Integer) -> String -> Bool
example f (f -> 4) = True
</programlisting>
That is, the scoping is the same as it would be if the curried arguments
were collected into a tuple.
were collected into a tuple.
</para>
</listitem>
......@@ -750,7 +750,7 @@ let {(x -> y) = e1 ;
(y -> x) = e2 } in x
</programlisting>
(For some amplification on this design choice see
(For some amplification on this design choice see
<ulink url="http://hackage.haskell.org/trac/ghc/ticket/4061">Trac #4061</ulink>.)
</para>
......@@ -771,8 +771,8 @@ a <replaceable>T2</replaceable>, then the whole view pattern matches a
<ulink url="http://www.haskell.org/onlinereport/">Haskell 98
Report</ulink>, add the following:
<programlisting>
case v of { (e -> p) -> e1 ; _ -> e2 }
=
case v of { (e -> p) -> e1 ; _ -> e2 }
=
case (e v) of { p -> e1 ; _ -> e2 }
</programlisting>
That is, to match a variable <replaceable>v</replaceable> against a pattern
......@@ -781,7 +781,7 @@ That is, to match a variable <replaceable>v</replaceable> against a pattern
<literal>)</literal>, evaluate <literal>(</literal>
<replaceable>exp</replaceable> <replaceable> v</replaceable>
<literal>)</literal> and match the result against
<replaceable>pat</replaceable>.
<replaceable>pat</replaceable>.
</para></listitem>
<listitem><para> Efficiency: When the same view function is applied in
......@@ -839,7 +839,7 @@ it, you can use the <option>-XNoNPlusKPatterns</option> flag.
<para>
The do-notation of Haskell 98 does not allow <emphasis>recursive bindings</emphasis>,
that is, the variables bound in a do-expression are visible only in the textually following
that is, the variables bound in a do-expression are visible only in the textually following
code block. Compare this to a let-expression, where bound variables are visible in the entire binding
group. It turns out that several applications can benefit from recursive bindings in
the do-notation. The <option>-XDoRec</option> flag provides the necessary syntactic support.
......@@ -857,7 +857,7 @@ As you can guess <literal>justOnes</literal> will evaluate to <literal>Just [-1,
The background and motivation for recursive do-notation is described in
<ulink url="http://sites.google.com/site/leventerkok/">A recursive do for Haskell</ulink>,
by Levent Erkok, John Launchbury,
Haskell Workshop 2002, pages: 29-37. Pittsburgh, Pennsylvania.
Haskell Workshop 2002, pages: 29-37. Pittsburgh, Pennsylvania.
The theory behind monadic value recursion is explained further in Erkok's thesis
<ulink url="http://sites.google.com/site/leventerkok/erkok-thesis.pdf">Value Recursion in Monadic Computations</ulink>.
However, note that GHC uses a different syntax than the one described in these documents.
......@@ -872,38 +872,38 @@ which wraps a mutually-recursive group of monadic statements,
producing a single statement.
</para>
<para>Similar to a <literal>let</literal>
statement, the variables bound in the <literal>rec</literal> are
statement, the variables bound in the <literal>rec</literal> are
visible throughout the <literal>rec</literal> group, and below it.
For example, compare
<programlisting>
do { a &lt;- getChar do { a &lt;- getChar
; let { r1 = f a r2 ; rec { r1 &lt;- f a r2
; r2 = g r1 } ; r2 &lt;- g r1 }
do { a &lt;- getChar do { a &lt;- getChar
; let { r1 = f a r2 ; rec { r1 &lt;- f a r2
; r2 = g r1 } ; r2 &lt;- g r1 }
; return (r1 ++ r2) } ; return (r1 ++ r2) }
</programlisting>
In both cases, <literal>r1</literal> and <literal>r2</literal> are
In both cases, <literal>r1</literal> and <literal>r2</literal> are
available both throughout the <literal>let</literal> or <literal>rec</literal> block, and
in the statements that follow it. The difference is that <literal>let</literal> is non-monadic,
while <literal>rec</literal> is monadic. (In Haskell <literal>let</literal> is
while <literal>rec</literal> is monadic. (In Haskell <literal>let</literal> is
really <literal>letrec</literal>, of course.)
</para>
<para>
The static and dynamic semantics of <literal>rec</literal> can be described as follows:
The static and dynamic semantics of <literal>rec</literal> can be described as follows:
<itemizedlist>
<listitem><para>
First,
similar to let-bindings, the <literal>rec</literal> is broken into
similar to let-bindings, the <literal>rec</literal> is broken into
minimal recursive groups, a process known as <emphasis>segmentation</emphasis>.
For example:
<programlisting>
rec { a &lt;- getChar ===> a &lt;- getChar
; b &lt;- f a c rec { b &lt;- f a c
; c &lt;- f b a ; c &lt;- f b a }
; putChar c } putChar c
; putChar c } putChar c
</programlisting>
The details of segmentation are described in Section 3.2 of
<ulink url="http://sites.google.com/site/leventerkok/">A recursive do for Haskell</ulink>.
Segmentation improves polymorphism, reduces the size of the recursive "knot", and, as the paper
Segmentation improves polymorphism, reduces the size of the recursive "knot", and, as the paper
describes, also has a semantic effect (unless the monad satisfies the right-shrinking law).
</para></listitem>
<listitem><para>
......@@ -921,13 +921,13 @@ is desugared to the statement
</programlisting>
where <replaceable>vs</replaceable> is a tuple of the variables bound by <replaceable>ss</replaceable>.
</para><para>
The original <literal>rec</literal> typechecks exactly
when the above desugared version would do so. For example, this means that
The original <literal>rec</literal> typechecks exactly
when the above desugared version would do so. For example, this means that
the variables <replaceable>vs</replaceable> are all monomorphic in the statements
following the <literal>rec</literal>, because they are bound by a lambda.
</para>
<para>
The <literal>mfix</literal> function is defined in the <literal>MonadFix</literal>
The <literal>mfix</literal> function is defined in the <literal>MonadFix</literal>
class, in <literal>Control.Monad.Fix</literal>, thus:
<programlisting>
class Monad m => MonadFix m where
......@@ -951,14 +951,14 @@ then that monad must be declared an instance of the <literal>MonadFix</literal>
</para></listitem>
<listitem><para>
The following instances of <literal>MonadFix</literal> are automatically provided: List, Maybe, IO.
Furthermore, the Control.Monad.ST and Control.Monad.ST.Lazy modules provide the instances of the MonadFix class
The following instances of <literal>MonadFix</literal> are automatically provided: List, Maybe, IO.
Furthermore, the Control.Monad.ST and Control.Monad.ST.Lazy modules provide the instances of the MonadFix class
for Haskell's internal state monad (strict and lazy, respectively).
</para></listitem>
<listitem><para>
Like <literal>let</literal> and <literal>where</literal> bindings,
name shadowing is not allowed within a <literal>rec</literal>;
name shadowing is not allowed within a <literal>rec</literal>;
that is, all the names bound in a single <literal>rec</literal> must
be distinct (Section 3.3 of the paper).
</para></listitem>
......@@ -1007,7 +1007,7 @@ This name is not supported by GHC.
example, the following zips together two lists:</para>
<programlisting>
[ (x, y) | x &lt;- xs | y &lt;- ys ]
[ (x, y) | x &lt;- xs | y &lt;- ys ]
</programlisting>
<para>The behavior of parallel list comprehensions follows that of
......@@ -1020,26 +1020,26 @@ This name is not supported by GHC.
<para>Given a parallel comprehension of the form: </para>
<programlisting>
[ e | p1 &lt;- e11, p2 &lt;- e12, ...
| q1 &lt;- e21, q2 &lt;- e22, ...
...
]
[ e | p1 &lt;- e11, p2 &lt;- e12, ...
| q1 &lt;- e21, q2 &lt;- e22, ...
...
]
</programlisting>
<para>This will be translated to: </para>
<programlisting>
[ e | ((p1,p2), (q1,q2), ...) &lt;- zipN [(p1,p2) | p1 &lt;- e11, p2 &lt;- e12, ...]
[(q1,q2) | q1 &lt;- e21, q2 &lt;- e22, ...]
...
]
[ e | ((p1,p2), (q1,q2), ...) &lt;- zipN [(p1,p2) | p1 &lt;- e11, p2 &lt;- e12, ...]
[(q1,q2) | q1 &lt;- e21, q2 &lt;- e22, ...]
...
]
</programlisting>
<para>where `zipN' is the appropriate zip for the given number of
branches.</para>
</sect2>
<!-- ===================== TRANSFORM LIST COMPREHENSIONS =================== -->
<sect2 id="generalised-list-comprehensions">
......@@ -1059,7 +1059,7 @@ This name is not supported by GHC.
Comprehensive comprehensions: comprehensions with "order by" and "group by"</ulink>,
except that the syntax we use differs slightly from the paper.</para>
<para>The extension is enabled with the flag <option>-XTransformListComp</option>.</para>
<para>Here is an example:
<para>Here is an example:
<programlisting>
employees = [ ("Simon", "MS", 80)
, ("Erik", "MS", 100)
......@@ -1073,9 +1073,9 @@ output = [ (the dept, sum salary)
, then sortWith by (sum salary)
, then take 5 ]
</programlisting>
In this example, the list <literal>output</literal> would take on
In this example, the list <literal>output</literal> would take on
the value:
<programlisting>
[("Yale", 60), ("Ed", 85), ("MS", 180)]
</programlisting>
......@@ -1088,7 +1088,7 @@ function that is exported by <literal>GHC.Exts</literal>.)</para>
all introduced by the (existing) keyword <literal>then</literal>:
<itemizedlist>
<listitem>
<programlisting>
then f
</programlisting>
......@@ -1096,10 +1096,10 @@ then f
This statement requires that <literal>f</literal> have the type <literal>
forall a. [a] -> [a]</literal>. You can see an example of its use in the
motivating example, as this form is used to apply <literal>take 5</literal>.
</listitem>
<listitem>
<para>
<programlisting>
......@@ -1107,13 +1107,13 @@ then f by e
</programlisting>
This form is similar to the previous one, but allows you to create a function
which will be passed as the first argument to f. As a consequence f must have
which will be passed as the first argument to f. As a consequence f must have
the type <literal>forall a. (a -> t) -> [a] -> [a]</literal>. As you can see
from the type, this function lets f &quot;project out&quot; some information
from the type, this function lets f &quot;project out&quot; some information
from the elements of the list it is transforming.</para>
<para>An example is shown in the opening example, where <literal>sortWith</literal>
is supplied with a function that lets it find out the <literal>sum salary</literal>
<para>An example is shown in the opening example, where <literal>sortWith</literal>
is supplied with a function that lets it find out the <literal>sum salary</literal>
for any item in the list comprehension it transforms.</para>
</listitem>
......@@ -1134,7 +1134,7 @@ then group by e using f
at every point after this statement, binders occurring before it in the comprehension
refer to <emphasis>lists</emphasis> of possible values, not single values. To help understand
this, let's look at an example:</para>
<programlisting>
-- This works similarly to groupWith in GHC.Exts, but doesn't sort its input first
groupRuns :: Eq b => (a -> b) -> [a] -> [[a]]
......@@ -1152,8 +1152,8 @@ output = [ (the x, y)
[(1, [4, 5, 6]), (2, [4, 5, 6]), (3, [4, 5, 6]), (1, [4, 5, 6]), (2, [4, 5, 6])]
</programlisting>
<para>Note that we have used the <literal>the</literal> function to change the type
of x from a list to its original numeric type. The variable y, in contrast, is left
<para>Note that we have used the <literal>the</literal> function to change the type
of x from a list to its original numeric type. The variable y, in contrast, is left
unchanged from the list form introduced by the grouping.</para>
</listitem>
......@@ -1166,13 +1166,13 @@ then group by e
<para>This form of grouping is essentially the same as the one described above. However,
since no function to use for the grouping has been supplied it will fall back on the
<literal>groupWith</literal> function defined in
<literal>groupWith</literal> function defined in
<ulink url="&libraryBaseLocation;/GHC-Exts.html"><literal>GHC.Exts</literal></ulink>. This
is the form of the group statement that we made use of in the opening example.</para>
</listitem>
<listitem>
<programlisting>
......@@ -1182,7 +1182,7 @@ then group using f
<para>With this form of the group statement, f is required to simply have the type
<literal>forall a. [a] -> [[a]]</literal>, which will be used to group up the
comprehension so far directly. An example of this form is as follows:</para>
<programlisting>
output = [ x
| y &lt;- [1..5]
......@@ -1208,10 +1208,10 @@ output = [ x
<indexterm><primary>monad comprehensions</primary></indexterm>
<para>
Monad comprehesions generalise the list comprehension notation,
including parallel comprehensions
(<xref linkend="parallel-list-comprehensions"/>) and
transform comprenensions (<xref linkend="generalised-list-comprehensions"/>)
Monad comprehensions generalise the list comprehension notation,
including parallel comprehensions
(<xref linkend="parallel-list-comprehensions"/>) and
transform comprehensions (<xref linkend="generalised-list-comprehensions"/>)
to work for any monad.
</para>
......@@ -1364,11 +1364,11 @@ do (x,y) &lt;- mzip (do x &lt;- [1..10]
compatible to built-in, transform and parallel list comprehensions.
</para>
<para> More formally, the desugaring is as follows. We write <literal>D[ e | Q]</literal>
to mean the desugaring of the monad comprehension <literal>[ e | Q]</literal>:
to mean the desugaring of the monad comprehension <literal>[ e | Q]</literal>:
<programlisting>
Expressions: e
Declarations: d
Lists of qualifiers: Q,R,S
Lists of qualifiers: Q,R,S
-- Basic forms
D[ e | ] = return e
......@@ -1384,11 +1384,11 @@ D[ e | Q then f, R ] = f D[ Qv | Q ] &gt;&gt;= \Qv -&gt; D[ e |
D[ e | Q then f by b, R ] = f b D[ Qv | Q ] &gt;&gt;= \Qv -&gt; D[ e | R ]
D[ e | Q then group using f, R ] = f D[ Qv | Q ] &gt;&gt;= \ys -&gt;
D[ e | Q then group using f, R ] = f D[ Qv | Q ] &gt;&gt;= \ys -&gt;
case (fmap selQv1 ys, ..., fmap selQvn ys) of
Qv -&gt; D[ e | R ]
D[ e | Q then group by b using f, R ] = f b D[ Qv | Q ] &gt;&gt;= \ys -&gt;
D[ e | Q then group by b using f, R ] = f b D[ Qv | Q ] &gt;&gt;= \ys -&gt;
case (fmap selQv1 ys, ..., fmap selQvn ys) of
Qv -&gt; D[ e | R ]
......@@ -1404,11 +1404,11 @@ guard Control.Monad t1 -&gt; m t2
fmap GHC.Base forall a b. (a-&gt;b) -&gt; n a -&gt; n b
mgroupWith Control.Monad.Group forall a. (a -&gt; t) -&gt; m1 a -&gt; m2 (n a)
mzip Control.Monad.Zip forall a b. m a -&gt; m b -&gt; m (a,b)
</programlisting>
The comprehension should typecheck when its desugaring would typecheck.
</programlisting>
The comprehension should typecheck when its desugaring would typecheck.
</para>
<para>
Monad comprehensions support rebindable syntax (<xref linkend="rebindable-syntax"/>).
Monad comprehensions support rebindable syntax (<xref linkend="rebindable-syntax"/>).
Without rebindable
syntax, the operators from the "standard binding" module are used; with
rebindable syntax, the operators are looked up in the current lexical scope.
......@@ -1416,7 +1416,7 @@ For example, parallel comprehensions will be typechecked and desugared
using whatever "<literal>mzip</literal>" is in scope.
</para>
<para>
The rebindable operators must have the "Expected type" given in the
The rebindable operators must have the "Expected type" given in the
table above. These types are surprisingly general. For example, you can
use a bind operator with the type
<programlisting>
......@@ -1449,7 +1449,7 @@ the comprehension being over an arbitrary monad.
hierarchy. It completely defeats that purpose if the
literal "1" means "<literal>Prelude.fromInteger
1</literal>", which is what the Haskell Report specifies.
So the <option>-XRebindableSyntax</option>
So the <option>-XRebindableSyntax</option>
flag causes
the following pieces of built-in syntax to refer to
<emphasis>whatever is in scope</emphasis>, not the Prelude
......@@ -1459,16 +1459,16 @@ the comprehension being over an arbitrary monad.
<para>An integer literal <literal>368</literal> means
"<literal>fromInteger (368::Integer)</literal>", rather than
"<literal>Prelude.fromInteger (368::Integer)</literal>".
</para> </listitem>
</para> </listitem>
<listitem><para>Fractional literals are handed in just the same way,
except that the translation is
except that the translation is
<literal>fromRational (3.68::Rational)</literal>.
</para> </listitem>
</para> </listitem>
<listitem><para>The equality test in an overloaded numeric pattern
uses whatever <literal>(==)</literal> is in scope.
</para> </listitem>
</para> </listitem>
<listitem><para>The subtraction operation, and the
greater-than-or-equal test, in <literal>n+k</literal> patterns
......@@ -1510,7 +1510,7 @@ the comprehension being over an arbitrary monad.
</para>
<para>
In all cases (apart from arrow notation), the static semantics should be that of the desugared form,
even if that is a little unexpected. For example, the
even if that is a little unexpected. For example, the
static semantics of the literal <literal>368</literal>
is exactly that of <literal>fromInteger (368::Integer)</literal>; it's fine for
<literal>fromInteger</literal> to have any of the types:
......@@ -1521,7 +1521,7 @@ fromInteger :: Num a => a -> Integer
fromInteger :: Integer -> Bool -> Bool
</programlisting>
</para>
<para>Be warned: this is an experimental facility, with
fewer checks than usual. Use <literal>-dcore-lint</literal>
to typecheck the desugared program. If Core Lint is happy
......@@ -1609,7 +1609,7 @@ module Foo where
import M
data T = MkT { x :: Int }
ok1 (MkS { x = n }) = n+1 -- Unambiguous
ok2 n = MkT { x = n+1 } -- Unambiguous
......@@ -1628,7 +1628,7 @@ it is not clear which of the two types is intended.
Haskell 98 regards all four as ambiguous, but with the
<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
declarations in Haskell 98, where the method names on the left-hand side
of the method bindings in an instance declaration refer unambiguously
to the method of that class (provided they are in scope at all), even
if there are other variables in scope with the same name.
......@@ -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.)
......@@ -1698,7 +1698,7 @@ f (C {a}) = a
to mean the same pattern as above. That is, in a record pattern, the
pattern <literal>a</literal> expands into the pattern <literal>a =
a</literal> for the same name <literal>a</literal>.
a</literal> for the same name <literal>a</literal>.
</para>
<para>
......@@ -1709,7 +1709,7 @@ Record punning can also be used in an expression, writing, for example,
<programlisting>
let a = 1 in C {a}
</programlisting>
instead of
instead of
<programlisting>
let a = 1 in C {a = a}
</programlisting>
......@@ -1728,7 +1728,7 @@ f (C {a, b = 4}) = a
<listitem><para>
Puns can be used wherever record patterns occur (e.g. in
<literal>let</literal> bindings or at the top-level).
<literal>let</literal> bindings or at the top-level).
</para></listitem>
<listitem><para>
......@@ -1811,9 +1811,9 @@ the same as the omitted field names.
</para></listitem>
<listitem><para>
The "<literal>..</literal>" expands to the missing
The "<literal>..</literal>" expands to the missing
<emphasis>in-scope</emphasis> record fields, where "in scope"
includes both unqualified and qualified-only.
includes both unqualified and qualified-only.
Any fields that are not in scope are not filled in. For example
<programlisting>
module M where
......@@ -1848,7 +1848,7 @@ the semantics of such bindings very precisely.
<programlisting>
let f = ...
infixr 3 `f`
in
in
...
</programlisting>
and the fixity declaration applies wherever the binding is in scope.
......@@ -1883,7 +1883,7 @@ necessary to enable them.
<programlisting>
import "network" Network.Socket
</programlisting>