<para> Language options recognised by Cabal can also be enabled using the <literal>LANGUAGE</literal> pragma,
thus <literal>{-# LANGUAGE TemplateHaskell #-}</literal> (see <xref linkend="language-pragma"/>>). </para>
- <para>The flag <option>-fglasgow-exts</option>:
+ <para>The flag <option>-fglasgow-exts</option>
<indexterm><primary><option>-fglasgow-exts</option></primary></indexterm>
- simultaneously enables the following extensions:
- <option>-XForeignFunctionInterface</option>,
- <option>-XImplicitParams</option>,
- <option>-XScopedTypeVariables</option>,
- <option>-XGADTs</option>,
- <option>-XTypeFamilies</option>.
+ is equivalent to enabling the following extensions:
+ <option>-XPrintExplicitForalls</option>,
+ <option>-XForeignFunctionInterface</option>,
+ <option>-XUnliftedFFITypes</option>,
+ <option>-XGADTs</option>,
+ <option>-XImplicitParams</option>,
+ <option>-XScopedTypeVariables</option>,
+ <option>-XUnboxedTuples</option>,
+ <option>-XTypeSynonymInstances</option>,
+ <option>-XStandaloneDeriving</option>,
+ <option>-XDeriveDataTypeable</option>,
+ <option>-XFlexibleContexts</option>,
+ <option>-XFlexibleInstances</option>,
+ <option>-XConstrainedClassMethods</option>,
+ <option>-XMultiParamTypeClasses</option>,
+ <option>-XFunctionalDependencies</option>,
+ <option>-XMagicHash</option>,
+ <option>-XPolymorphicComponents</option>,
+ <option>-XExistentialQuantification</option>,
+ <option>-XUnicodeSyntax</option>,
+ <option>-XPostfixOperators</option>,
+ <option>-XPatternGuards</option>,
+ <option>-XLiberalTypeSynonyms</option>,
+ <option>-XRankNTypes</option>,
+ <option>-XImpredicativeTypes</option>,
+ <option>-XTypeOperators</option>,
+ <option>-XRecursiveDo</option>,
+ <option>-XParallelListComp</option>,
+ <option>-XEmptyDataDecls</option>,
+ <option>-XKindSignatures</option>,
+ <option>-XGeneralizedNewtypeDeriving</option>,
+ <option>-XTypeFamilies</option>.
Enabling these options is the <emphasis>only</emphasis>
- effect of <options>-fglasgow-exts</options>
+ effect of <options>-fglasgow-exts</options>.
We are trying to move away from this portmanteau flag,
and towards enabling features individually.</para>
</para>
</sect2>
+ <sect2>
+ <title>New qualified operator syntax</title>
+
+ <para>A new syntax for referencing qualified operators is
+ planned to be introduced by Haskell', and is enabled in GHC
+ with
+ the <option>-XNewQualifiedOperators</option><indexterm><primary><option>-XNewQualifiedOperators</option></primary></indexterm>
+ option. In the new syntax, the prefix form of a qualified
+ operator is
+ written <literal><replaceable>module</replaceable>.(<replaceable>symbol</replaceable>)</literal>
+ (in Haskell 98 this would
+ be <literal>(<replaceable>module</replaceable>.<replaceable>symbol</replaceable>)</literal>),
+ and the infix form is
+ written <literal>`<replaceable>module</replaceable>.(<replaceable>symbol</replaceable>)`</literal>
+ (in Haskell 98 this would
+ be <literal>`<replaceable>module</replaceable>.<replaceable>symbol</replaceable>`</literal>.
+ For example:
+<programlisting>
+ add x y = Prelude.(+) x y
+ subtract y = (`Prelude.(-)` y)
+</programlisting>
+ The new form of qualified operators is intended to regularise
+ the syntax by eliminating odd cases
+ like <literal>Prelude..</literal>. For example,
+ when <literal>NewQualifiedOperators</literal> is on, it is possible to
+ write the enerated sequence <literal>[Monday..]</literal>
+ without spaces, whereas in Haskell 98 this would be a
+ reference to the operator ‘<literal>.</literal>‘
+ from module <literal>Monday</literal>.</para>
+
+ <para>When <option>-XNewQualifiedOperators</option> is on, the old Haskell
+ 98 syntax for qualified operators is not accepted, so this
+ option may cause existing Haskell 98 code to break.</para>
+
+ </sect2>
+
+
<!-- ====================== HIERARCHICAL MODULES ======================= -->
for example in a <literal>case</literal> expression, the following rules apply:
<itemizedlist>
<listitem><para>The type of the scrutinee must be rigid.</para></listitem>
-<listitem><para>The type of the result of the <literal>case</literal> expression must be rigid.</para></listitem>
+<listitem><para>The type of the entire <literal>case</literal> expression must be rigid.</para></listitem>
<listitem><para>The type of any free variable mentioned in any of
the <literal>case</literal> alternatives must be rigid.</para></listitem>
</itemizedlist>
A type is "rigid" if it is completely known to the compiler at its binding site. The easiest
way to ensure that a variable a rigid type is to give it a type signature.
+For more precise details see <ulink url="http://research.microsoft.com/%7Esimonpj/papers/gadt">
+Simple unification-based type inference for GADTs
+</ulink>. The criteria implemented by GHC are given in the Appendix.
+
</para></listitem>
</itemizedlist>
<emphasis>check</emphasis> that <literal>f</literal> has the specified type.
Suppose instead we do not give a type signature, asking GHC to <emphasis>infer</emphasis>
it instead. In this case, GHC will refrain from
-simplifying the constraint <literal>C Int [Int]</literal> (for the same reason
+simplifying the constraint <literal>C Int [b]</literal> (for the same reason
as before) but, rather than rejecting the program, it will infer the type
<programlisting>
- f :: C Int b => [b] -> [b]
+ f :: C Int [b] => [b] -> [b]
</programlisting>
That postpones the question of which instance to pick to the
call site for <literal>f</literal>
by which time more is known about the type <literal>b</literal>.
+You can write this type signature yourself if you use the
+<link linkend="flexible-contexts"><option>-XFlexibleContexts</option></link>
+flag.
+</para>
+<para>
+Exactly the same situation can arise in instance declarations themselves. Suppose we have
+<programlisting>
+ class Foo a where
+ f :: a -> a
+ instance Foo [b] where
+ f x = ...
+</programlisting>
+and, as before, the constraint <literal>C Int [b]</literal> arises from <literal>f</literal>'s
+right hand side. GHC will reject the instance, complaining as before that it does not know how to resolve
+the constraint <literal>C Int [b]</literal>, because it matches more than one instance
+declaration. The solution is to postpone the choice by adding the constraint to the context
+of the instance declaration, thus:
+<programlisting>
+ instance C Int [b] => Foo [b] where
+ f x = ...
+</programlisting>
+(You need <link linkend="instance-rules"><option>-XFlexibleInstances</option></link> to do this.)
</para>
<para>
The willingness to be overlapped or incoherent is a property of
<sect3 id="flexible-contexts"><title>The context of a type signature</title>
<para>
-Unlike Haskell 98, constraints in types do <emphasis>not</emphasis> have to be of
-the form <emphasis>(class type-variable)</emphasis> or
-<emphasis>(class (type-variable type-variable ...))</emphasis>. Thus,
+The <option>-XFlexibleContexts</option> flag lifts the Haskell 98 restriction
+that the type-class constraints in a type signature must have the
+form <emphasis>(class type-variable)</emphasis> or
+<emphasis>(class (type-variable type-variable ...))</emphasis>.
+With <option>-XFlexibleContexts</option>
these type signatures are perfectly OK
<programlisting>
g :: Eq [a] => ...
“Generalising Monads to Arrows”,
John Hughes, in <citetitle>Science of Computer Programming</citetitle> 37,
pp67–111, May 2000.
+The paper that introduced arrows: a friendly introduction, motivated with
+programming examples.
</para>
</listitem>
<para>
“<ulink url="http://www.soi.city.ac.uk/~ross/papers/notation.html">A New Notation for Arrows</ulink>”,
Ross Paterson, in <citetitle>ICFP</citetitle>, Sep 2001.
+Introduced the notation described here.
</para>
</listitem>
</para>
</listitem>
-</itemizedlist>
-and the arrows web page at
+<listitem>
+<para>
+“<ulink url="http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf">Programming with Arrows</ulink>”,
+John Hughes, in <citetitle>5th International Summer School on
+Advanced Functional Programming</citetitle>,
+<citetitle>Lecture Notes in Computer Science</citetitle> vol. 3622,
+Springer, 2004.
+This paper includes another introduction to the notation,
+with practical examples.
+</para>
+</listitem>
+
+<listitem>
+<para>
+“<ulink url="http://www.haskell.org/ghc/docs/papers/arrow-rules.pdf">Type and Translation Rules for Arrow Notation in GHC</ulink>”,
+Ross Paterson and Simon Peyton Jones, September 16, 2004.
+A terse enumeration of the formal rules used
+(extracted from comments in the source code).
+</para>
+</listitem>
+
+<listitem>
+<para>
+The arrows web page at
<ulink url="http://www.haskell.org/arrows/"><literal>http://www.haskell.org/arrows/</literal></ulink>.
+</para>
+</listitem>
+
+</itemizedlist>
With the <option>-XArrows</option> flag, GHC supports the arrow
-notation described in the second of these papers.
-What follows is a brief introduction to the notation;
-it won't make much sense unless you've read Hughes's paper.
-This notation is translated to ordinary Haskell,
-using combinators from the
+notation described in the second of these papers,
+translating it using combinators from the
<ulink url="../libraries/base/Control-Arrow.html"><literal>Control.Arrow</literal></ulink>
module.
+What follows is a brief introduction to the notation;
+it won't make much sense unless you've read Hughes's paper.
</para>
<para>The extension adds a new kind of expression for defining arrows:
<programlisting>
untilA :: ArrowChoice a => a e () -> a e Bool -> a e ()
untilA body cond = proc x ->
- if cond x then returnA -< ()
+ b <- cond -< x
+ if b then returnA -< ()
else do
body -< x
untilA body cond -< x