[project @ 2005-03-09 17:47:09 by simonpj]

[ghc-hetmet.git] / ghc / docs / users_guide / glasgow_exts.xml

diff --git a/ghc/docs/users_guide/glasgow_exts.xml b/ghc/docs/users_guide/glasgow_exts.xml
index efd7a13..0b73fbe 100644 (file)
--- a/ghc/docs/users_guide/glasgow_exts.xml
+++ b/ghc/docs/users_guide/glasgow_exts.xml
@@ -925,11 +925,11 @@ Nevertheless, they can be useful when defining "phantom types".</para>
 </sect3>
 
 <sect3 id="infix-tycons">
-<title>Infix type constructors and classes</title>
+<title>Infix type constructors, classes, and type variables</title>
 
 <para>
-GHC allows type constructors and classes to be operators, and to be written infix, very much 
-like expressions.  More specifically:
+GHC allows type constructors, classes, and type variables to be operators, and
+to be written infix, very much like expressions.  More specifically:
 <itemizedlist>
 <listitem><para>
   A type constructor or class can be an operator, beginning with a colon; e.g. <literal>:*:</literal>.
@@ -955,6 +955,21 @@ like expressions.  More specifically:
   </screen>
   </para></listitem>
 <listitem><para>
+  A type variable can be an (unqualified) operator e.g. <literal>+</literal>.
+  The lexical syntax is the same as that for variable operators, excluding "(.)",
+  "(!)", and "(*)".  In a binding position, the operator must be
+  parenthesised.  For example:
+<programlisting>
+   type T (+) = Int + Int
+   f :: T Either
+   f = Left 3
+ 
+   liftA2 :: Arrow (~>)
+         => (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c)
+   liftA2 = ...
+</programlisting>
+  </para></listitem>
+<listitem><para>
   Back-quotes work
   as for expressions, both for type constructors and type variables;  e.g. <literal>Int `Either` Bool</literal>, or
   <literal>Int `a` Bool</literal>.  Similarly, parentheses work the same; e.g.  <literal>(:*:) Int Bool</literal>.
@@ -973,14 +988,6 @@ like expressions.  More specifically:
 <listitem><para>
   Function arrow is <literal>infixr</literal> with fixity 0.  (This might change; I'm not sure what it should be.)
   </para></listitem>
-<listitem><para>
-  The only thing that differs between operators in types and operators in expressions is that
-  ordinary non-constructor operators, such as <literal>+</literal> and <literal>*</literal>
-  are not allowed in types. Reason: the uniform thing to do would be to make them type
-  variables, but that's not very useful.  A less uniform but more useful thing would be to
-  allow them to be type <emphasis>constructors</emphasis>.  But that gives trouble in export
-  lists.  So for now we just exclude them.
-  </para></listitem>
 
 </itemizedlist>
 </para>
@@ -2108,6 +2115,68 @@ the binding for <literal>?x</literal>, so the type of <literal>f</literal> is
 </para>
 
 </sect3>
+
+<sect3><title>Implicit parameters and polymorphic recursion</title>
+
+<para>
+Consider these two definitions:
+<programlisting>
+  len1 :: [a] -> Int
+  len1 xs = let ?acc = 0 in len_acc1 xs
+
+  len_acc1 [] = ?acc
+  len_acc1 (x:xs) = let ?acc = ?acc + (1::Int) in len_acc1 xs
+
+  ------------
+
+  len2 :: [a] -> Int
+  len2 xs = let ?acc = 0 in len_acc2 xs
+
+  len_acc2 :: (?acc :: Int) => [a] -> Int
+  len_acc2 [] = ?acc
+  len_acc2 (x:xs) = let ?acc = ?acc + (1::Int) in len_acc2 xs
+</programlisting>
+The only difference between the two groups is that in the second group
+<literal>len_acc</literal> is given a type signature.
+In the former case, <literal>len_acc1</literal> is monomorphic in its own
+right-hand side, so the implicit parameter <literal>?acc</literal> is not
+passed to the recursive call.  In the latter case, because <literal>len_acc2</literal>
+has a type signature, the recursive call is made to the
+<emphasis>polymoprhic</emphasis> version, which takes <literal>?acc</literal>
+as an implicit parameter.  So we get the following results in GHCi:
+<programlisting>
+  Prog> len1 "hello"
+  0
+  Prog> len2 "hello"
+  5
+</programlisting>
+Adding a type signature dramatically changes the result!  This is a rather
+counter-intuitive phenomenon, worth watching out for.
+</para>
+</sect3>
+
+<sect3><title>Implicit parameters and monomorphism</title>
+
+<para>GHC applies the dreaded Monomorphism Restriction (section 4.5.5 of the
+Haskell Report) to implicit parameters.  For example, consider:
+<programlisting>
+ f :: Int -> Int
+  f v = let ?x = 0     in
+        let y = ?x + v in
+        let ?x = 5     in
+        y
+</programlisting>
+Since the binding for <literal>y</literal> falls under the Monomorphism
+Restriction it is not generalised, so the type of <literal>y</literal> is
+simply <literal>Int</literal>, not <literal>(?x::Int) => Int</literal>.
+Hence, <literal>(f 9)</literal> returns result <literal>9</literal>.
+If you add a type signature for <literal>y</literal>, then <literal>y</literal>
+will get type <literal>(?x::Int) => Int</literal>, so the occurrence of
+<literal>y</literal> in the body of the <literal>let</literal> will see the
+inner binding of <literal>?x</literal>, so <literal>(f 9)</literal> will return
+<literal>14</literal>.
+</para>
+</sect3>
 </sect2>
 
 <sect2 id="linear-implicit-parameters">