</term>
<listitem>
<para>This option enables the language extension defined in the
- Haskell 98 Foreign Function Interface Addendum plus deprecated
- syntax of previous versions of the FFI for backwards
- compatibility.</para>
+ Haskell 98 Foreign Function Interface Addendum.</para>
<para>New reserved words: <literal>foreign</literal>.</para>
</listitem>
<varlistentry>
<term>
- <option>-fno-monomorphism-restriction</option>,<option>-fno-monomorphism-restriction</option>:
+ <option>-fno-monomorphism-restriction</option>,<option>-fno-mono-pat-binds</option>:
</term>
<listitem>
<para> These two flags control how generalisation is done.
you should be all right.</para>
</sect2>
+
+<sect2 id="postfix-operators">
+<title>Postfix operators</title>
+
+<para>
+GHC allows a small extension to the syntax of left operator sections, which
+allows you to define postfix operators. The extension is this: the left section
+<programlisting>
+ (e !)
+</programlisting>
+is equivalent (from the point of view of both type checking and execution) to the expression
+<programlisting>
+ ((!) e)
+</programlisting>
+(for any expression <literal>e</literal> and operator <literal>(!)</literal>.
+The strict Haskell 98 interpretation is that the section is equivalent to
+<programlisting>
+ (\y -> (!) e y)
+</programlisting>
+That is, the operator must be a function of two arguments. GHC allows it to
+take only one argument, and that in turn allows you to write the function
+postfix.
+</para>
+<para>Since this extension goes beyond Haskell 98, it should really be enabled
+by a flag; but in fact it is enabled all the time. (No Haskell 98 programs
+change their behaviour, of course.)
+</para>
+<para>The extension does not extend to the left-hand side of function
+definitions; you must define such a function in prefix form.</para>
+
+</sect2>
+
</sect1>
</programlisting>
The type signature for <literal>f</literal> brings the type variable <literal>a</literal> into scope; it scopes over
the entire definition of <literal>f</literal>.
-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>ys</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.
A <emphasis>lexically scoped type variable</emphasis> can be bound by:
<itemizedlist>
<listitem><para>A declaration type signature (<xref linkend="decl-type-sigs"/>)</para></listitem>
+<listitem><para>An expression type signature (<xref linkend="exp-type-sigs"/>)</para></listitem>
<listitem><para>A pattern type signature (<xref linkend="pattern-type-sigs"/>)</para></listitem>
<listitem><para>Class and instance declarations (<xref linkend="cls-inst-scoped-tyvars"/>)</para></listitem>
</itemizedlist>
</para>
</sect3>
+<sect3 id="exp-type-sigs">
+<title>Expression type signatures</title>
+
+<para>An expression type signature that has <emphasis>explicit</emphasis>
+quantification (using <literal>forall</literal>) brings into scope the
+explicitly-quantified
+type variables, in the annotated expression. For example:
+<programlisting>
+ f = runST ( (op >>= \(x :: STRef s Int) -> g x) :: forall s. ST s Bool )
+</programlisting>
+Here, the type signature <literal>forall a. ST s Bool</literal> brings the
+type variable <literal>s</literal> into scope, in the annotated expression
+<literal>(op >>= \(x :: STRef s Int) -> g x)</literal>.
+</para>
+
+</sect3>
+
<sect3 id="pattern-type-sigs">
<title>Pattern type signatures</title>
<para>
For example:
<programlisting>
-- f and g assume that 'a' is already in scope
- f = \(x::Int, y) -> x
+ f = \(x::Int, y::a) -> x
g (x::a) = x
h ((x,y) :: (Int,Bool)) = (y,x)
</programlisting>
where
<itemizedlist>
<listitem><para>
- The type <literal>t</literal> is an arbitrary type
+ The <literal>ci</literal> are partial applications of
+ classes of the form <literal>C t1'...tj'</literal>, where the arity of <literal>C</literal>
+ is exactly <literal>j+1</literal>. That is, <literal>C</literal> lacks exactly one type argument.
</para></listitem>
<listitem><para>
- The <literal>vk+1...vn</literal> are type variables which do not occur in
- <literal>t</literal>, and
+ The <literal>k</literal> is chosen so that <literal>ci (T v1...vk)</literal> is well-kinded.
</para></listitem>
<listitem><para>
- The <literal>ci</literal> are partial applications of
- classes of the form <literal>C t1'...tj'</literal>, where the arity of <literal>C</literal>
- is exactly <literal>j+1</literal>. That is, <literal>C</literal> lacks exactly one type argument.
+ The type <literal>t</literal> is an arbitrary type.
+</para></listitem>
+<listitem><para>
+ The type variables <literal>vk+1...vn</literal> do not occur in <literal>t</literal>,
+ nor in the <literal>ci</literal>, and
</para></listitem>
<listitem><para>
None of the <literal>ci</literal> is <literal>Read</literal>, <literal>Show</literal>,
Then, for each <literal>ci</literal>, the derived instance
declaration is:
<programlisting>
- instance ci (t vk+1...v) => ci (T v1...vp)
+ instance ci t => ci (T v1...vk)
</programlisting>
-where <literal>p</literal> is chosen so that <literal>T v1...vp</literal> is of the
-right <emphasis>kind</emphasis> for the last parameter of class <literal>Ci</literal>.
-</para>
-<para>
-
As an example which does <emphasis>not</emphasis> work, consider
<programlisting>
newtype NonMonad m s = NonMonad (State s m s) deriving Monad
</sect2>
+<sect2 id="stand-alone-deriving">
+<title>Stand-alone deriving declarations</title>
+
+<para>
+GHC now allows stand-alone <literal>deriving</literal> declarations:
+</para>
+
+<programlisting>
+ data Foo = Bar Int | Baz String
+
+ deriving Eq for Foo
+</programlisting>
+
+<para>Deriving instances of multi-parameter type classes for newtypes is
+also allowed:</para>
+
+<programlisting>
+ newtype Foo a = MkFoo (State Int a)
+
+ deriving (MonadState Int) for Foo
+</programlisting>
+
+<para>
+</para>
+
+</sect2>
+
<sect2 id="typing-binds">
<title>Generalised typing of mutually recursive bindings</title>
<!-- ====================== Generalised algebraic data types ======================= -->
<sect1 id="gadt">
-<title>Generalised Algebraic Data Types</title>
+<title>Generalised Algebraic Data Types (GADTs)</title>
-<para>Generalised Algebraic Data Types (GADTs) generalise ordinary algebraic data types by allowing you
+<para>Generalised Algebraic Data Types generalise ordinary algebraic data types by allowing you
to give the type signatures of constructors explicitly. For example:
<programlisting>
data Term a where
eval (If b e1 e2) = if eval b then eval e1 else eval e2
eval (Pair e1 e2) = (eval e1, eval e2)
</programlisting>
-These and many other examples are given in papers by Hongwei Xi, and Tim Sheard.
+These and many other examples are given in papers by Hongwei Xi, and
+Tim Sheard. There is a longer introduction
+<ulink url="http://haskell.org/haskellwiki/GADT">on the wiki</ulink>,
+and Ralf Hinze's
+<ulink url="http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf">Fun with phantom types</ulink> also has a number of examples. Note that papers
+may use different notation to that implemented in GHC.
</para>
<para>
The rest of this section outlines the extensions to GHC that support GADTs.
Haskell-98 syntax. For example, these two declarations are equivalent
<programlisting>
data Maybe1 a where {
- Nothing1 :: Maybe a ;
- Just1 :: a -> Maybe a
+ Nothing1 :: Maybe1 a ;
+ Just1 :: a -> Maybe1 a
} deriving( Eq, Ord )
data Maybe2 a = Nothing2 | Just2 a
</programlisting>
Is this a definition of the infix function "<literal>(!)</literal>",
or of the "<literal>f</literal>" with a bang pattern? GHC resolves this
-ambiguity inf favour of the latter. If you want to define
+ambiguity in favour of the latter. If you want to define
<literal>(!)</literal> with bang-patterns enabled, you have to do so using
prefix notation:
<programlisting>
GHCziBase.ZMZN GHCziBase.Char -> GHCziBase.ZMZN GHCziBase.Cha
r) ->
tpl2})
- (%note "foo"
+ (%note "bar"
eta);
</programlisting>
described in this section. All are exported by
<literal>GHC.Exts</literal>.</para>
+<sect2> <title>The <literal>seq</literal> function </title>
+<para>
+The function <literal>seq</literal> is as described in the Haskell98 Report.
+<programlisting>
+ seq :: a -> b -> b
+</programlisting>
+It evaluates its first argument to head normal form, and then returns its
+second argument as the result. The reason that it is documented here is
+that, despite <literal>seq</literal>'s polymorphism, its
+second argument can have an unboxed type, or
+can be an unboxed tuple; for example <literal>(seq x 4#)</literal>
+or <literal>(seq x (# p,q #))</literal>. This requires <literal>b</literal>
+to be instantiated to an unboxed type, which is not usually allowed.
+</para>
+</sect2>
+
<sect2> <title>The <literal>inline</literal> function </title>
<para>
The <literal>inline</literal> function is somewhat experimental.
look strict in <literal>y</literal> which would defeat the whole
purpose of <literal>par</literal>.
</para>
+<para>
+Like <literal>seq</literal>, the argument of <literal>lazy</literal> can have
+an unboxed type.
+</para>
+
</sect2>
<sect2> <title>The <literal>unsafeCoerce#</literal> function </title>
well-typed, but where Haskell's type system is not expressive enough to prove
that it is well typed.
</para>
+<para>
+The argument to <literal>unsafeCoerce#</literal> can have unboxed types,
+although extremely bad things will happen if you coerce a boxed type
+to an unboxed type.
+</para>
+
</sect2>
+
</sect1>
<sect1 id="generic-classes">
<title>Generic classes</title>
- <para>(Note: support for generic classes is currently broken in
- GHC 5.02).</para>
-
<para>
The ideas behind this extension are described in detail in "Derivable type classes",
Ralf Hinze and Simon Peyton Jones, Haskell Workshop, Montreal Sept 2000, pp94-105.