<listitem>
<para>This simultaneously enables all of the extensions to
Haskell 98 described in <xref
- linkend="ghc-language-features">, except where otherwise
+ linkend="ghc-language-features"/>, except where otherwise
noted. </para>
<para>New reserved words: <literal>forall</literal> (only in
<indexterm><primary><option>-fallow-undecidable-instances</option></primary></indexterm>
<indexterm><primary><option>-fcontext-stack</option></primary></indexterm>
<listitem>
- <para> See <xref LinkEnd="instance-decls">. Only relevant
+ <para> See <xref linkend="instance-decls"/>. Only relevant
if you also use <option>-fglasgow-exts</option>.</para>
</listitem>
</varlistentry>
<term><option>-finline-phase</option></term>
<indexterm><primary><option>-finline-phase</option></primary></indexterm>
<listitem>
- <para>See <xref LinkEnd="rewrite-rules">. Only relevant if
+ <para>See <xref linkend="rewrite-rules"/>. Only relevant if
you also use <option>-fglasgow-exts</option>.</para>
</listitem>
</varlistentry>
<term><option>-farrows</option></term>
<indexterm><primary><option>-farrows</option></primary></indexterm>
<listitem>
- <para>See <xref LinkEnd="arrow-notation">. Independent of
+ <para>See <xref linkend="arrow-notation"/>. Independent of
<option>-fglasgow-exts</option>.</para>
<para>New reserved words/symbols: <literal>rec</literal>,
<term><option>-fgenerics</option></term>
<indexterm><primary><option>-fgenerics</option></primary></indexterm>
<listitem>
- <para>See <xref LinkEnd="generic-classes">. Independent of
+ <para>See <xref linkend="generic-classes"/>. Independent of
<option>-fglasgow-exts</option>.</para>
</listitem>
</varlistentry>
<para>However, <option>-fno-implicit-prelude</option> does
change the handling of certain built-in syntax: see <xref
- LinkEnd="rebindable-syntax">.</para>
+ linkend="rebindable-syntax"/>.</para>
</listitem>
</varlistentry>
<term><option>-fth</option></term>
<listitem>
<para>Enables Template Haskell (see <xref
- linkend="template-haskell">). Currently also implied by
+ linkend="template-haskell"/>). Currently also implied by
<option>-fglasgow-exts</option>.</para>
<para>Syntax stolen: <literal>[|</literal>,
<term><option>-fimplicit-params</option></term>
<listitem>
<para>Enables implicit parameters (see <xref
- linkend="implicit-parameters">). Currently also implied by
+ linkend="implicit-parameters"/>). Currently also implied by
<option>-fglasgow-exts</option>.</para>
<para>Syntax stolen:
<para>For details on how GHC searches for source and interface
files in the presence of hierarchical modules, see <xref
- linkend="search-path">.</para>
+ linkend="search-path"/>.</para>
<para>GHC comes with a large collection of libraries arranged
hierarchically; see the accompanying library documentation.
<para>
<indexterm><primary>Pattern guards (Glasgow extension)</primary></indexterm>
-The discussion that follows is an abbreviated version of Simon Peyton Jones's original <ULink URL="http://research.microsoft.com/~simonpj/Haskell/guards.html">proposal</ULink>. (Note that the proposal was written before pattern guards were implemented, so refers to them as unimplemented.)
+The discussion that follows is an abbreviated version of Simon Peyton Jones's original <ulink URL="http://research.microsoft.com/~simonpj/Haskell/guards.html">proposal</ulink>. (Note that the proposal was written before pattern guards were implemented, so refers to them as unimplemented.)
</para>
<para>
</programlisting>
The lookup returns <function>Nothing</function> if the supplied key is not in the domain of the mapping, and <function>(Just v)</function> otherwise,
-where <VarName>v</VarName> is the value that the key maps to. Now consider the following definition:
+where <varname>v</varname> is the value that the key maps to. Now consider the following definition:
</para>
<programlisting>
-clunky env var1 var2 | ok1 && ok2 = val1 + val2
+clunky env var1 var2 | ok1 && ok2 = val1 + val2
| otherwise = var1 + var2
where
m1 = lookup env var1
</programlisting>
<para>
-What is <function>clunky</function> doing? The guard <literal>ok1 &&
+What is <function>clunky</function> doing? The guard <literal>ok1 &&
ok2</literal> checks that both lookups succeed, using
<function>maybeToBool</function> to convert the <function>Maybe</function>
types to booleans. The (lazily evaluated) <function>expectJust</function>
calls extract the values from the results of the lookups, and binds the
-returned values to <VarName>val1</VarName> and <VarName>val2</VarName>
+returned values to <varname>val1</varname> and <varname>val2</varname>
respectively. If either lookup fails, then clunky takes the
<literal>otherwise</literal> case and returns the sum of its arguments.
</para>
</para>
<programlisting>
-f x | [y] <- x
+f x | [y] <- x
, y > 3
- , Just z <- h y
+ , Just z <- h y
= ...
</programlisting>
<programlisting>
import Control.Monad.Fix
-justOnes = mdo xs <- Just (1:xs)
+justOnes = mdo xs <- Just (1:xs)
return xs
</programlisting>
<para>
example, the following zips together two lists:</para>
<programlisting>
- [ (x, y) | x <- xs | y <- ys ]
+ [ (x, y) | x <- xs | y <- ys ]
</programlisting>
<para>The behavior of parallel list comprehensions follows that of
<para>Given a parallel comprehension of the form: </para>
<programlisting>
- [ e | p1 <- e11, p2 <- e12, ...
- | q1 <- e21, q2 <- e22, ...
+ [ e | p1 <- e11, p2 <- e12, ...
+ | q1 <- e21, q2 <- e22, ...
...
]
</programlisting>
<para>This will be translated to: </para>
<programlisting>
- [ e | ((p1,p2), (q1,q2), ...) <- zipN [(p1,p2) | p1 <- e11, p2 <- e12, ...]
- [(q1,q2) | q1 <- e21, q2 <- e22, ...]
+ [ e | ((p1,p2), (q1,q2), ...) <- zipN [(p1,p2) | p1 <- e11, p2 <- e12, ...]
+ [(q1,q2) | q1 <- e21, q2 <- e22, ...]
...
]
</programlisting>
<para>Syntactically, the declaration lacks the "= constrs" part. The
type can be parameterised over types of any kind, but if the kind is
not <literal>*</literal> then an explicit kind annotation must be used
-(see <xref linkend="sec-kinding">).</para>
+(see <xref linkend="sec-kinding"/>).</para>
<para>Such data types have only one value, namely bottom.
Nevertheless, they can be useful when defining "phantom types".</para>
The idea of using existential quantification in data type declarations
was suggested by Laufer (I believe, thought doubtless someone will
correct me), and implemented in Hope+. It's been in Lennart
-Augustsson's <Command>hbc</Command> Haskell compiler for several years, and
+Augustsson's <command>hbc</command> Haskell compiler for several years, and
proved very useful. Here's the idea. Consider the declaration:
</para>
<title>Type classes</title>
<para>
-An easy extension (implemented in <Command>hbc</Command>) is to allow
+An easy extension (implemented in <command>hbc</command>) is to allow
arbitrary contexts before the constructor. For example:
</para>
(MkT a) == (MkT b) = ???
</programlisting>
-But <VarName>a</VarName> and <VarName>b</VarName> have distinct types, and so can't be compared.
+But <varname>a</varname> and <varname>b</varname> have distinct types, and so can't be compared.
It's just about possible to imagine examples in which the derived instance
would make sense, but it seems altogether simpler simply to prohibit such
declarations. Define your own instances!
<para>
This section documents GHC's implementation of multi-parameter type
-classes. There's lots of background in the paper <ULink
+classes. There's lots of background in the paper <ulink
URL="http://research.microsoft.com/~simonpj/multi.ps.gz" >Type
-classes: exploring the design space</ULink > (Simon Peyton Jones, Mark
+classes: exploring the design space</ulink > (Simon Peyton Jones, Mark
Jones, Erik Meijer).
</para>
<para>
There are the following constraints on class declarations:
-<OrderedList>
+<orderedlist>
<listitem>
<para>
<para>
<emphasis>All of the class type variables must be reachable (in the sense
-mentioned in <xref linkend="type-restrictions">)
+mentioned in <xref linkend="type-restrictions"/>)
from the free varibles of each method type
</emphasis>. For example:
</para>
</listitem>
-</OrderedList>
+</orderedlist>
</para>
<sect3 id="class-method-types">
language omits them; in Haskell 98, all the free type variables of an
explicit source-language type signature are universally quantified,
except for the class type variables in a class declaration. However,
-in GHC, you can give the foralls if you want. See <xref LinkEnd="universal-quantification">).
+in GHC, you can give the foralls if you want. See <xref linkend="universal-quantification"/>).
</para>
<para>
-<OrderedList>
+<orderedlist>
<listitem>
<para>
that the reachability condition is weaker than saying that <literal>a</literal> is
functionally dependendent on a type variable free in
<literal>type</literal> (see <xref
-linkend="functional-dependencies">). The reason for this is there
+linkend="functional-dependencies"/>). The reason for this is there
might be a "hidden" dependency, in a superclass perhaps. So
"reachable" is a conservative approximation to "functionally dependent".
For example, consider:
</para>
</listitem>
-</OrderedList>
+</orderedlist>
</para>
</sect3>
<sect3 id="hoist">
<title>For-all hoisting</title>
<para>
-It is often convenient to use generalised type synonyms (see <xref linkend="type-synonyms">) at the right hand
+It is often convenient to use generalised type synonyms (see <xref linkend="type-synonyms"/>) at the right hand
end of an arrow, thus:
<programlisting>
type Discard a = forall b. a -> b -> a
is not OK.
</para>
</listitem>
-</OrderedList>
+</orderedlist>
These restrictions ensure that
context reduction terminates: each reduction step removes one type
constructor. For example, the following would make the type checker
<literal>cmp</literal>.
<programlisting>
min :: [a] -> a
- min = let ?cmp = (<=) in least
+ min = let ?cmp = (<=) in least
</programlisting>
</para>
<para>
just as it is nice to give a type signature for a function. On some occasions,
it is essential to do so. For example, in his paper "Restricted Data Types in Haskell" (Haskell Workshop 1999)
John Hughes had to define the data type:
-<Screen>
+<screen>
data Set cxt a = Set [a]
| Unused (cxt a -> ())
-</Screen>
+</screen>
The only use for the <literal>Unused</literal> constructor was to force the correct
kind for the type variable <literal>cxt</literal>.
</para>
a type variable is explicitly bound. Namely:
<itemizedlist>
<listitem><para><literal>data</literal> declarations:
-<Screen>
+<screen>
data Set (cxt :: * -> *) a = Set [a]
-</Screen></para></listitem>
+</screen></para></listitem>
<listitem><para><literal>type</literal> declarations:
-<Screen>
+<screen>
type T (f :: * -> *) = f Int
-</Screen></para></listitem>
+</screen></para></listitem>
<listitem><para><literal>class</literal> declarations:
-<Screen>
+<screen>
class (Eq a) => C (f :: * -> *) a where ...
-</Screen></para></listitem>
+</screen></para></listitem>
<listitem><para><literal>forall</literal>'s in type signatures:
-<Screen>
+<screen>
f :: forall (cxt :: * -> *). Set cxt Int
-</Screen></para></listitem>
+</screen></para></listitem>
</itemizedlist>
</para>
<para>
As part of the same extension, you can put kind annotations in types
as well. Thus:
-<Screen>
+<screen>
f :: (Int :: *) -> Int
g :: forall a. a -> (a :: *)
-</Screen>
+</screen>
The syntax is
-<Screen>
+<screen>
atype ::= '(' ctype '::' kind ')
-</Screen>
+</screen>
The parentheses are required.
</para>
</sect2>
including an operational type class context, is legal:
<itemizedlist>
<listitem> <para> On the left of a function arrow </para> </listitem>
-<listitem> <para> On the right of a function arrow (see <xref linkend="hoist">) </para> </listitem>
+<listitem> <para> On the right of a function arrow (see <xref linkend="hoist"/>) </para> </listitem>
<listitem> <para> As the argument of a constructor, or type of a field, in a data type declaration. For
example, any of the <literal>f1,f2,f3,g1,g2</literal> above would be valid
field type signatures.</para> </listitem>
<listitem> <para> As the type of an implicit parameter </para> </listitem>
-<listitem> <para> In a pattern type signature (see <xref linkend="scoped-type-variables">) </para> </listitem>
+<listitem> <para> In a pattern type signature (see <xref linkend="scoped-type-variables"/>) </para> </listitem>
</itemizedlist>
There is one place you cannot put a <literal>forall</literal>:
you cannot instantiate a type variable with a forall-type. So you cannot
<para>
What does it mean to "provide" an explicit type for x? You can do that by
giving a type signature for x directly, using a pattern type signature
-(<xref linkend="scoped-type-variables">), thus:
+(<xref linkend="scoped-type-variables"/>), thus:
<programlisting>
\ f :: (forall a. a->a) -> (f True, f 'c')
</programlisting>
</para>
<para>
-The pattern <literal>(xs::[a])</literal> includes a type signature for <VarName>xs</VarName>.
+The pattern <literal>(xs::[a])</literal> includes a type signature for <varname>xs</varname>.
This brings the type variable <literal>a</literal> into scope; it scopes over
all the patterns and right hand sides for this equation for <function>f</function>.
-In particular, it is in scope at the type signature for <VarName>y</VarName>.
+In particular, it is in scope at the type signature for <varname>y</varname>.
</para>
<para>
Pattern type signatures are completely orthogonal to ordinary, separate
type signatures. The two can be used independently or together.
-At ordinary type signatures, such as that for <VarName>ys</VarName>, any type variables
+At ordinary type signatures, such as that for <varname>ys</varname>, any type variables
mentioned in the type signature <emphasis>that are not in scope</emphasis> are
implicitly universally quantified. (If there are no type variables in
scope, all type variables mentioned in the signature are universally
-quantified, which is just as in Haskell 98.) In this case, since <VarName>a</VarName>
-is in scope, it is not universally quantified, so the type of <VarName>ys</VarName> is
-the same as that of <VarName>xs</VarName>. In Haskell 98 it is not possible to declare
-a type for <VarName>ys</VarName>; a major benefit of scoped type variables is that
+quantified, which is just as in Haskell 98.) In this case, since <varname>a</varname>
+is in scope, it is not universally quantified, so the type of <varname>ys</varname> is
+the same as that of <varname>xs</varname>. In Haskell 98 it is not possible to declare
+a type for <varname>ys</varname>; a major benefit of scoped type variables is that
it becomes possible to do so.
</para>
as the term variable(s) bound by the pattern. For example:
<programlisting>
let
- f (x::a) = <...rhs of f...>
+ f (x::a) = <...rhs of f...>
(p::b, q::b) = (1,2)
- in <...body of let...>
+ in <...body of let...>
</programlisting>
Here, the type variable <literal>a</literal> scopes over the right hand side of <literal>f</literal>,
just like <literal>x</literal> does; while the type variable <literal>b</literal> scopes over the
f x = x::a
</programlisting>
-It's illegal because <VarName>a</VarName> is not in scope in the body of <function>f</function>,
+It's illegal because <varname>a</varname> is not in scope in the body of <function>f</function>,
so the ordinary signature <literal>x::a</literal> is equivalent to <literal>x::forall a.a</literal>;
and that is an incorrect typing.
returnA
</screen>
Note that variables not used later in the composition are projected out.
-After simplification using rewrite rules (see <xref linkEnd="rewrite-rules">)
+After simplification using rewrite rules (see <xref linkend="rewrite-rules"/>)
defined in the
<ulink url="../base/Control.Arrow.html"><literal>Control.Arrow</literal></ulink>
module, this reduces to
For example, we could simulate <literal>do</literal>-notation by defining
<programlisting>
bind :: Arrow a => a e b -> a (e,b) c -> a e c
-u `bind` f = returnA &&& u >>> f
+u `bind` f = returnA &&& u >>> f
bind_ :: Arrow a => a e b -> a e c -> a e c
u `bind_` f = u `bind` (arr fst >>> f)
</programlisting>
<para>See also the <literal>NOINLINE</literal> pragma (<xref
- linkend="noinline-pragma">).</para>
+ linkend="noinline-pragma"/>).</para>
</sect3>
<sect3 id="noinline-pragma">
</itemizedlist>
<para>The same phase-numbering control is available for RULES
- (<xref LinkEnd="rewrite-rules">).</para>
+ (<xref linkend="rewrite-rules"/>).</para>
</sect3>
</sect2>
<para>The <literal>OPTIONS</literal> pragma is used to specify
additional options that are given to the compiler when compiling
- this source file. See <xref linkend="source-file-options"> for
+ this source file. See <xref linkend="source-file-options"/> for
details.</para>
</sect2>
<title>RULES pragma</title>
<para>The RULES pragma lets you specify rewrite rules. It is
- described in <xref LinkEnd="rewrite-rules">.</para>
+ described in <xref linkend="rewrite-rules"/>.</para>
</sect2>
<sect2 id="specialize-pragma">
<para>A <literal>SPECIALIZE</literal> has the effect of generating
(a) a specialised version of the function and (b) a rewrite rule
- (see <xref linkend="rewrite-rules">) that rewrites a call to the
+ (see <xref linkend="rewrite-rules"/>) that rewrites a call to the
un-specialised function into a call to the specialised one.</para>
<para>In earlier versions of GHC, it was possible to provide your own
</programlisting>
This feature has been removed, as it is now subsumed by the
- <literal>RULES</literal> pragma (see <xref linkend="rule-spec">).</para>
+ <literal>RULES</literal> pragma (see <xref linkend="rule-spec"/>).</para>
</sect2>
the constructor itself, removing a level of indirection. For
example:</para>
-<ProgramListing>
+<programlisting>
data T = T {-# UNPACK #-} !Float
{-# UNPACK #-} !Float
-</ProgramListing>
+</programlisting>
<para>will create a constructor <literal>T</literal> containing
two unboxed floats. This may not always be an optimisation: if
- the <Function>T</Function> constructor is scrutinised and the
+ the <function>T</function> constructor is scrutinised and the
floats passed to a non-strict function for example, they will
have to be reboxed (this is done automatically by the
compiler).</para>
unfoldings to the compiler so the reboxing can be removed as
often as possible. For example:</para>
-<ProgramListing>
+<programlisting>
f :: T -> Float
f (T f1 f2) = f1 + f2
-</ProgramListing>
+</programlisting>
- <para>The compiler will avoid reboxing <Function>f1</Function>
- and <Function>f2</Function> by inlining <Function>+</Function>
+ <para>The compiler will avoid reboxing <function>f1</function>
+ and <function>f2</function> by inlining <function>+</function>
on floats, but only when <option>-O</option> is on.</para>
<para>Any single-constructor data is eligible for unpacking; for
example</para>
-<ProgramListing>
+<programlisting>
data T = T {-# UNPACK #-} !(Int,Int)
-</ProgramListing>
+</programlisting>
<para>will store the two <literal>Int</literal>s directly in the
- <Function>T</Function> constructor, by flattening the pair.
+ <function>T</function> constructor, by flattening the pair.
Multi-level unpacking is also supported:</para>
-<ProgramListing>
+<programlisting>
data T = T {-# UNPACK #-} !S
data S = S {-# UNPACK #-} !Int {-# UNPACK #-} !Int
-</ProgramListing>
+</programlisting>
<para>will store two unboxed <literal>Int#</literal>s
- directly in the <Function>T</Function> constructor. The
+ directly in the <function>T</function> constructor. The
unpacker can see through newtypes, too.</para>
<para>If a field cannot be unpacked, you will not get a warning,
<para>
The programmer can specify rewrite rules as part of the source program
(in a pragma). GHC applies these rewrite rules wherever it can, provided (a)
-the <option>-O</option> flag (<xref LinkEnd="options-optimise">) is on,
+the <option>-O</option> flag (<xref linkend="options-optimise"/>) is on,
and (b) the <option>-frules-off</option> flag
-(<xref LinkEnd="options-f">) is not specified.
+(<xref linkend="options-f"/>) is not specified.
</para>
<para>
<listitem>
<para>
-A rule may optionally have a phase-control number (see <xref LinkEnd="phase-control">),
+A rule may optionally have a phase-control number (see <xref linkend="phase-control"/>),
immediately after the name of the rule. Thus:
<programlisting>
{-# RULES
<para>
Matching is carried out on GHC's intermediate language, which includes
type abstractions and applications. So a rule only matches if the
-types match too. See <xref LinkEnd="rule-spec"> below.
+types match too. See <xref linkend="rule-spec"/> below.
</para>
</listitem>
<listitem>
</programlisting>
The expression <literal>s (t xs)</literal> does not match the rule <literal>"map/map"</literal>, but GHC
-will substitute for <VarName>s</VarName> and <VarName>t</VarName>, giving an expression which does match.
-If <VarName>s</VarName> or <VarName>t</VarName> was (a) used more than once, and (b) large or a redex, then it would
+will substitute for <varname>s</varname> and <varname>t</varname>, giving an expression which does match.
+If <varname>s</varname> or <varname>t</varname> was (a) used more than once, and (b) large or a redex, then it would
not be substituted, and the rule would not fire.
</para>
<listitem>
<para>
- The defintion of (say) <function>build</function> in <FileName>GHC/Base.lhs</FileName> looks llike this:
+ The defintion of (say) <function>build</function> in <filename>GHC/Base.lhs</filename> looks llike this:
<programlisting>
build :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
<para>
However, when external for is generated (via
<option>-fext-core</option>), there will be Notes attached to the
- expressions <function>show</function> and <VarName>x</VarName>.
+ expressions <function>show</function> and <varname>x</varname>.
The core function declaration for <function>f</function> is:
</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>).
+ expression <varname>eta</varname> (which used to be called
+ <varname>x</varname>).
</para>
</sect2>
projects / ghc-hetmet.git / blobdiff