<indexterm><primary>language, GHC</primary></indexterm>
<indexterm><primary>extensions, GHC</primary></indexterm>
As with all known Haskell systems, GHC implements some extensions to
-the language. To use them, you'll need to give a <option>-fglasgow-exts</option>
-<indexterm><primary>-fglasgow-exts option</primary></indexterm> option.
+the language. They are all enabled by options; by default GHC
+understands only plain Haskell 98.
</para>
<para>
-Virtually all of the Glasgow extensions serve to give you access to
-the underlying facilities with which we implement Haskell. Thus, you
-can get at the Raw Iron, if you are willing to write some non-standard
-code at a more primitive level. You need not be “stuck” on
-performance because of the implementation costs of Haskell's
-“high-level” features—you can always code “under” them. In an extreme case, you can write all your time-critical code in C, and then just glue it together with Haskell!
+Some of the Glasgow extensions serve to give you access to the
+underlying facilities with which we implement Haskell. Thus, you can
+get at the Raw Iron, if you are willing to write some non-portable
+code at a more primitive level. You need not be “stuck”
+on performance because of the implementation costs of Haskell's
+“high-level” features—you can always code
+“under” them. In an extreme case, you can write all your
+time-critical code in C, and then just glue it together with Haskell!
</para>
<para>
sloshing <literal>MutableByteArray#</literal>s around your
program), you may wish to check if there are libraries that provide a
“Haskellised veneer” over the features you want. The
-separate libraries documentation describes all the libraries that come
-with GHC.
+separate <ulink url="../libraries/index.html">libraries
+documentation</ulink> describes all the libraries that come with GHC.
</para>
<!-- LANGUAGE OPTIONS -->
<indexterm><primary>extensions</primary><secondary>options controlling</secondary>
</indexterm>
- <para> These flags control what variation of the language are
+ <para>These flags control what variation of the language are
permitted. Leaving out all of them gives you standard Haskell
98.</para>
+ <para>NB. turning on an option that enables special syntax
+ <emphasis>might</emphasis> cause working Haskell 98 code to fail
+ to compile, perhaps because it uses a variable name which has
+ become a reserved word. So, together with each option below, we
+ list the special syntax which is enabled by this option. We use
+ notation and nonterminal names from the Haskell 98 lexical syntax
+ (see the Haskell 98 Report). There are two classes of special
+ syntax:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>New reserved words and symbols: character sequences
+ which are no longer available for use as identifiers in the
+ program.</para>
+ </listitem>
+ <listitem>
+ <para>Other special syntax: sequences of characters that have
+ a different meaning when this particular option is turned
+ on.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>We are only listing syntax changes here that might affect
+ existing working programs (i.e. "stolen" syntax). Many of these
+ extensions will also enable new context-free syntax, but in all
+ cases programs written to use the new syntax would not be
+ compilable without the option enabled.</para>
+
<variablelist>
<varlistentry>
<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
+ types), <literal>mdo</literal>.</para>
+
+ <para>Other syntax stolen:
+ <replaceable>varid</replaceable>{<literal>#</literal>},
+ <replaceable>char</replaceable><literal>#</literal>,
+ <replaceable>string</replaceable><literal>#</literal>,
+ <replaceable>integer</replaceable><literal>#</literal>,
+ <replaceable>float</replaceable><literal>#</literal>,
+ <replaceable>float</replaceable><literal>##</literal>,
+ <literal>(#</literal>, <literal>#)</literal>,
+ <literal>|)</literal>, <literal>{|</literal>.</para>
</listitem>
</varlistentry>
Haskell 98 Foreign Function Interface Addendum plus deprecated
syntax of previous versions of the FFI for backwards
compatibility.</para>
+
+ <para>New reserved words: <literal>foreign</literal>.</para>
</listitem>
</varlistentry>
<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>,
+ <literal>proc</literal>, <literal>-<</literal>,
+ <literal>>-</literal>, <literal>-<<</literal>,
+ <literal>>>-</literal>.</para>
+
+ <para>Other syntax stolen: <literal>(|</literal>,
+ <literal>|)</literal>.</para>
</listitem>
</varlistentry>
<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>,
+ <literal>[e|</literal>, <literal>[p|</literal>,
+ <literal>[d|</literal>, <literal>[t|</literal>,
+ <literal>$(</literal>,
+ <literal>$<replaceable>varid</replaceable></literal>.</para>
</listitem>
</varlistentry>
<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:
+ <literal>?<replaceable>varid</replaceable></literal>,
+ <literal>%<replaceable>varid</replaceable></literal>.</para>
</listitem>
</varlistentry>
<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>
<emphasis>Each universally quantified type variable
<literal>tvi</literal> must be reachable from <literal>type</literal></emphasis>.
-A type variable is "reachable" if it it is functionally dependent
-(see <xref linkend="functional-dependencies">)
-on the type variables free in <literal>type</literal>.
-The reason for this is that a value with a type that does not obey
-this restriction could not be used without introducing
-ambiguity.
+A type variable <literal>a</literal> is "reachable" if it it appears
+in the same constraint as either a type variable free in in
+<literal>type</literal>, or another reachable type variable.
+A value with a type that does not obey
+this reachability restriction cannot be used without introducing
+ambiguity; that is why the type is rejected.
Here, for example, is an illegal type:
applied to a dictionary for <literal>Eq tv</literal>. The difficulty is that we
can never know which instance of <literal>Eq</literal> to use because we never
get any more information about <literal>tv</literal>.
-
+</para>
+<para>
+Note
+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
+might be a "hidden" dependency, in a superclass perhaps. So
+"reachable" is a conservative approximation to "functionally dependent".
+For example, consider:
+<programlisting>
+ class C a b | a -> b where ...
+ class C a b => D a b where ...
+ f :: forall a b. D a b => a -> a
+</programlisting>
+This is fine, because in fact <literal>a</literal> does functionally determine <literal>b</literal>
+but that is not immediately apparent from <literal>f</literal>'s type.
</para>
</listitem>
<listitem>
</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.
-- you intend to use it.
-- Import some Template Haskell syntax
-import Language.Haskell.THSyntax
+import Language.Haskell.TH.Syntax
-- Describe a format string
data Format = D | S | L String
it won't make much sense unless you've read Hughes's paper.
This notation is translated to ordinary Haskell,
using combinators from the
-<ulink url="../base/Control.Arrow.html"><literal>Control.Arrow</literal></ulink>
+<ulink url="../libraries/base/Control.Arrow.html"><literal>Control.Arrow</literal></ulink>
module.
</para>
-<para>The extension adds a new kind of expression for defining arrows,
-of the form <literal>proc pat -> cmd</literal>,
+<para>The extension adds a new kind of expression for defining arrows:
+<screen>
+<replaceable>exp</replaceable><superscript>10</superscript> ::= ...
+ | proc <replaceable>apat</replaceable> -> <replaceable>cmd</replaceable>
+</screen>
where <literal>proc</literal> is a new keyword.
The variables of the pattern are bound in the body of the
<literal>proc</literal>-expression,
which is a new sort of thing called a <firstterm>command</firstterm>.
The syntax of commands is as follows:
<screen>
-cmd ::= exp1 -< exp2
- | exp1 -<< exp2
- | do { cstmt1 .. cstmtn ; cmd }
- | let decls in cmd
- | if exp then cmd1 else cmd2
- | case exp of { calts }
- | cmd1 qop cmd2
- | (| aexp cmd1 .. cmdn |)
- | \ pat1 .. patn -> cmd
- | cmd aexp
- | ( cmd )
-
-cstmt ::= let decls
- | pat <- cmd
- | rec { cstmt1 .. cstmtn }
- | cmd
+<replaceable>cmd</replaceable> ::= <replaceable>exp</replaceable><superscript>10</superscript> -< <replaceable>exp</replaceable>
+ | <replaceable>exp</replaceable><superscript>10</superscript> -<< <replaceable>exp</replaceable>
+ | <replaceable>cmd</replaceable><superscript>0</superscript>
+</screen>
+with <replaceable>cmd</replaceable><superscript>0</superscript> up to
+<replaceable>cmd</replaceable><superscript>9</superscript> defined using
+infix operators as for expressions, and
+<screen>
+<replaceable>cmd</replaceable><superscript>10</superscript> ::= \ <replaceable>apat</replaceable> ... <replaceable>apat</replaceable> -> <replaceable>cmd</replaceable>
+ | let <replaceable>decls</replaceable> in <replaceable>cmd</replaceable>
+ | if <replaceable>exp</replaceable> then <replaceable>cmd</replaceable> else <replaceable>cmd</replaceable>
+ | case <replaceable>exp</replaceable> of { <replaceable>calts</replaceable> }
+ | do { <replaceable>cstmt</replaceable> ; ... <replaceable>cstmt</replaceable> ; <replaceable>cmd</replaceable> }
+ | <replaceable>fcmd</replaceable>
+
+<replaceable>fcmd</replaceable> ::= <replaceable>fcmd</replaceable> <replaceable>aexp</replaceable>
+ | ( <replaceable>cmd</replaceable> )
+ | (| <replaceable>aexp</replaceable> <replaceable>cmd</replaceable> ... <replaceable>cmd</replaceable> |)
+
+<replaceable>cstmt</replaceable> ::= let <replaceable>decls</replaceable>
+ | <replaceable>pat</replaceable> <- <replaceable>cmd</replaceable>
+ | rec { <replaceable>cstmt</replaceable> ; ... <replaceable>cstmt</replaceable> [;] }
+ | <replaceable>cmd</replaceable>
</screen>
+where <replaceable>calts</replaceable> are like <replaceable>alts</replaceable>
+except that the bodies are commands instead of expressions.
+</para>
+
+<para>
Commands produce values, but (like monadic computations)
may yield more than one value,
or none, and may do other things as well.
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
</programlisting>
so we can use it to build commands:
<programlisting>
-expr' = proc x ->
+expr' = proc x -> do
returnA -< x
<+> do
symbol Plus -< ()
y <- term -< ()
expr' -< x - y
</programlisting>
+(The <literal>do</literal> on the first line is needed to prevent the first
+<literal><+> ...</literal> from being interpreted as part of the
+expression on the previous line.)
This is equivalent to
<programlisting>
expr' = (proc x -> returnA -< x)
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> pragma for a function can
be put anywhere its type signature could be put.</para>
-<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="rules">) that
-rewrites a call to the un-specialised function into a call to the specialised
-one. You can, instead, provide your own specialised function and your own rewrite rule.
-For example, suppose that:
-<programlisting>
- genericLookup :: Ord a => Table a b -> a -> b
- intLookup :: Table Int b -> Int -> b
-</programlisting>
-where <literal>intLookup</literal> is an implementation of <literal>genericLookup</literal>
-that works very fast for keys of type <literal>Int</literal>. Then you can write the rule
-<programlisting>
- {-# RULES "intLookup" genericLookup = intLookup #-}
-</programlisting>
-(see <xref linkend="rule-spec">). It is <emphasis>Your
- Responsibility</emphasis> to make sure that
- <function>intLookup</function> really behaves as a specialised
- version of <function>genericLookup</function>!!!</para>
+ <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
+ un-specialised function into a call to the specialised one.</para>
- <para>An example in which using <literal>RULES</literal> for
- specialisation will Win Big:
+ <para>In earlier versions of GHC, it was possible to provide your own
+ specialised function for a given type:
<programlisting>
- toDouble :: Real a => a -> Double
- toDouble = fromRational . toRational
-
- {-# RULES "toDouble/Int" toDouble = i2d #-}
- i2d (I# i) = D# (int2Double# i) -- uses Glasgow prim-op directly
+{-# SPECIALIZE hammeredLookup :: [(Int, value)] -> Int -> value = intLookup #-}
</programlisting>
- The <function>i2d</function> function is virtually one machine
- instruction; the default conversion—via an intermediate
- <literal>Rational</literal>—is obscenely expensive by
- comparison.</para>
+ This feature has been removed, as it is now subsumed by the
+ <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>
<para>
Rewrite rules can be used to get the same effect as a feature
-present in earlier version of GHC:
+present in earlier versions of GHC.
+For example, suppose that:
<programlisting>
- {-# SPECIALIZE fromIntegral :: Int8 -> Int16 = int8ToInt16 #-}
+genericLookup :: Ord a => Table a b -> a -> b
+intLookup :: Table Int b -> Int -> b
</programlisting>
-This told GHC to use <function>int8ToInt16</function> instead of <function>fromIntegral</function> whenever
-the latter was called with type <literal>Int8 -> Int16</literal>. That is, rather than
-specialising the original definition of <function>fromIntegral</function> the programmer is
-promising that it is safe to use <function>int8ToInt16</function> instead.
-</para>
-
-<para>
-This feature is no longer in GHC. But rewrite rules let you do the
-same thing:
+where <function>intLookup</function> is an implementation of
+<function>genericLookup</function> that works very fast for
+keys of type <literal>Int</literal>. You might wish
+to tell GHC to use <function>intLookup</function> instead of
+<function>genericLookup</function> whenever the latter was called with
+type <literal>Table Int b -> Int -> b</literal>.
+It used to be possible to write
<programlisting>
-{-# RULES
- "fromIntegral/Int8/Int16" fromIntegral = int8ToInt16
-#-}
+{-# SPECIALIZE genericLookup :: Table Int b -> Int -> b = intLookup #-}
</programlisting>
-This slightly odd-looking rule instructs GHC to replace <function>fromIntegral</function>
-by <function>int8ToInt16</function> <emphasis>whenever the types match</emphasis>. Speaking more operationally,
-GHC adds the type and dictionary applications to get the typed rule
+This feature is no longer in GHC, but rewrite rules let you do the same thing:
<programlisting>
-forall (d1::Integral Int8) (d2::Num Int16) .
- fromIntegral Int8 Int16 d1 d2 = int8ToInt16
+{-# RULES "genericLookup/Int" genericLookup = intLookup #-}
</programlisting>
-What is more,
-this rule does not need to be in the same file as fromIntegral,
-unlike the <literal>SPECIALISE</literal> pragmas which currently do (so that they
+This slightly odd-looking rule instructs GHC to replace
+<function>genericLookup</function> by <function>intLookup</function>
+<emphasis>whenever the types match</emphasis>.
+What is more, this rule does not need to be in the same
+file as <function>genericLookup</function>, unlike the
+<literal>SPECIALIZE</literal> pragmas which currently do (so that they
have an original definition available to specialise).
</para>
+<para>It is <emphasis>Your Responsibility</emphasis> to make sure that
+<function>intLookup</function> really behaves as a specialised version
+of <function>genericLookup</function>!!!</para>
+
+<para>An example in which using <literal>RULES</literal> for
+specialisation will Win Big:
+
+<programlisting>
+toDouble :: Real a => a -> Double
+toDouble = fromRational . toRational
+
+{-# RULES "toDouble/Int" toDouble = i2d #-}
+i2d (I# i) = D# (int2Double# i) -- uses Glasgow prim-op directly
+</programlisting>
+
+The <function>i2d</function> function is virtually one machine
+instruction; the default conversion—via an intermediate
+<literal>Rational</literal>—is obscenely expensive by
+comparison.
+</para>
+
</sect2>
<sect2>
<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