in a <emphasis>recursive</emphasis> binding.
</para></listitem>
<listitem><para> You may bind unboxed variables in a (non-recursive,
-non-top-level) pattern binding, but any such variable causes the entire
-pattern-match
-to become strict. For example:
+non-top-level) pattern binding, but you must make any such pattern-match
+strict. For example, rather than:
<programlisting>
data Foo = Foo Int Int#
f x = let (Foo a b, w) = ..rhs.. in ..body..
</programlisting>
-Since <literal>b</literal> has type <literal>Int#</literal>, the entire pattern
-match
-is strict, and the program behaves as if you had written
+you must write:
<programlisting>
data Foo = Foo Int Int#
- f x = case ..rhs.. of { (Foo a b, w) -> ..body.. }
+ f x = let !(Foo a b, w) = ..rhs.. in ..body..
</programlisting>
+since <literal>b</literal> has type <literal>Int#</literal>.
</para>
</listitem>
</itemizedlist>
<sect1 id="syntax-extns">
<title>Syntactic extensions</title>
+ <sect2 id="unicode-syntax">
+ <title>Unicode syntax</title>
+ <para>The language
+ extension <option>-XUnicodeSyntax</option><indexterm><primary><option>-XUnicodeSyntax</option></primary></indexterm>
+ enables Unicode characters to be used to stand for certain ASCII
+ character sequences. The following alternatives are provided:</para>
+
+ <informaltable>
+ <tgroup cols="2" align="left" colsep="1" rowsep="1">
+ <thead>
+ <row>
+ <entry>ASCII</entry>
+ <entry>Unicode alternative</entry>
+ <entry>Code point</entry>
+ <entry>Name</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>::</literal></entry>
+ <entry>::</entry> <!-- no special char, apparently -->
+ <entry>0x2237</entry>
+ <entry>PROPORTION</entry>
+ </row>
+ </tbody>
+ <tbody>
+ <row>
+ <entry><literal>=></literal></entry>
+ <entry>⇒</entry>
+ <entry>0x21D2</entry>
+ <entry>RIGHTWARDS DOUBLE ARROW</entry>
+ </row>
+ </tbody>
+ <tbody>
+ <row>
+ <entry><literal>forall</literal></entry>
+ <entry>∀</entry>
+ <entry>0x2200</entry>
+ <entry>FOR ALL</entry>
+ </row>
+ </tbody>
+ <tbody>
+ <row>
+ <entry><literal>-></literal></entry>
+ <entry>→</entry>
+ <entry>0x2192</entry>
+ <entry>RIGHTWARDS ARROW</entry>
+ </row>
+ </tbody>
+ <tbody>
+ <row>
+ <entry><literal><-</literal></entry>
+ <entry>←</entry>
+ <entry>0x2190</entry>
+ <entry>LEFTWARDS ARROW</entry>
+ </row>
+ </tbody>
+ <tbody>
+ <row>
+ <entry>..</entry>
+ <entry>…</entry>
+ <entry>0x22EF</entry>
+ <entry>MIDLINE HORIZONTAL ELLIPSIS</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </sect2>
+
<sect2 id="magic-hash">
<title>The magic hash</title>
<para>The language extension <option>-XMagicHash</option> allows "#" as a
paper <ulink url="http://research.microsoft.com/~simonpj/papers/list-comp">
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:
<programlisting>
employees = [ ("Simon", "MS", 80)
</para></listitem>
<listitem><para>
+As with other type signatures, you can give a single signature for several data constructors.
+In this example we give a single signature for <literal>T1</literal> and <literal>T2</literal>:
+<programlisting>
+ data T a where
+ T1,T2 :: a -> T a
+ T3 :: T a
+</programlisting>
+</para></listitem>
+
+<listitem><para>
The type signature of
each constructor is independent, and is implicitly universally quantified as usual.
Different constructors may have different universally-quantified type variables
<sect2 id="deriving-typeable">
-<title>Deriving clause for classes <literal>Typeable</literal> and <literal>Data</literal></title>
+<title>Deriving clause for extra classes (<literal>Typeable</literal>, <literal>Data</literal>, etc)</title>
<para>
Haskell 98 allows the programmer to add "<literal>deriving( Eq, Ord )</literal>" to a data type
<literal>Enum</literal>, <literal>Ix</literal>, <literal>Bounded</literal>, <literal>Read</literal>, and <literal>Show</literal>.
</para>
<para>
-GHC extends this list with two more classes that may be automatically derived
-(provided the <option>-XDeriveDataTypeable</option> flag is specified):
-<literal>Typeable</literal>, and <literal>Data</literal>. These classes are defined in the library
-modules <literal>Data.Typeable</literal> and <literal>Data.Generics</literal> respectively, and the
-appropriate class must be in scope before it can be mentioned in the <literal>deriving</literal> clause.
+GHC extends this list with several more classes that may be automatically derived:
+<itemizedlist>
+<listitem><para> With <option>-XDeriveDataTypeable</option>, you can derive instances of the classes
+<literal>Typeable</literal>, and <literal>Data</literal>, defined in the library
+modules <literal>Data.Typeable</literal> and <literal>Data.Generics</literal> respectively.
</para>
<para>An instance of <literal>Typeable</literal> can only be derived if the
data type has seven or fewer type parameters, all of kind <literal>*</literal>.
class, whose kind suits that of the data type constructor, and
then writing the data type instance by hand.
</para>
+</listitem>
+
+<listitem><para> With <option>-XDeriveFunctor</option>, you can derive instances of
+the class <literal>Functor</literal>,
+defined in <literal>GHC.Base</literal>.
+</para></listitem>
+
+<listitem><para> With <option>-XDeriveFoldable</option>, you can derive instances of
+the class <literal>Foldable</literal>,
+defined in <literal>Data.Foldable</literal>.
+</para></listitem>
+
+<listitem><para> With <option>-XDeriveTraversable</option>, you can derive instances of
+the class <literal>Traversable</literal>,
+defined in <literal>Data.Traversable</literal>.
+</para></listitem>
+</itemizedlist>
+In each case the appropriate class must be in scope before it
+can be mentioned in the <literal>deriving</literal> clause.
+</para>
</sect2>
<sect2 id="newtype-deriving">
<itemizedlist>
<listitem><para> an expression; the spliced expression must
have type <literal>Q Exp</literal></para></listitem>
+ <listitem><para> an type; the spliced expression must
+ have type <literal>Q Typ</literal></para></listitem>
<listitem><para> a list of top-level declarations; the spliced expression must have type <literal>Q [Dec]</literal></para></listitem>
</itemizedlist>
</para>
(Compared to the original paper, there are many differences of detail.
The syntax for a declaration splice uses "<literal>$</literal>" not "<literal>splice</literal>".
The type of the enclosed expression must be <literal>Q [Dec]</literal>, not <literal>[Q Dec]</literal>.
-Type splices are not implemented, and neither are pattern splices or quotations.
+Pattern splices and quotations are not implemented.)
</sect2>
please give the GHC team a shout</ulink>.
</para>
- <para>However, apart from these restrictions, many things are allowed, including expressions which not fully evaluated!
+ <para>However, apart from these restrictions, many things are allowed, including expressions which are not fully evaluated!
Annotation expressions will be evaluated by the compiler just like Template Haskell splices are. So, this annotation is fine:</para>
<programlisting>