Repository : ssh://darcs.haskell.org//srv/darcs/ghc

On branch  : master

http://hackage.haskell.org/trac/ghc/changeset/9929172c72c7a61ba7b20c084e72d41299835e44

>---------------------------------------------------------------

commit 9929172c72c7a61ba7b20c084e72d41299835e44
Author: Ben Millwood <thebenmachine+...@gmail.com>
Date:   Wed Dec 26 23:24:49 2012 +0000

    Remove references to GHC 6.6 in docs

>---------------------------------------------------------------

 docs/users_guide/glasgow_exts.xml |  180 -------------------------------------
 1 files changed, 0 insertions(+), 180 deletions(-)

diff --git a/docs/users_guide/glasgow_exts.xml 
b/docs/users_guide/glasgow_exts.xml
index 433aa8f..93279aa 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -6234,183 +6234,6 @@ inner binding of <literal>?x</literal>, so <literal>(f 
9)</literal> will return
 </sect3>
 </sect2>
 
-    <!--   ======================= COMMENTED OUT ========================
-
-    We intend to remove linear implicit parameters, so I'm at least removing
-    them from the 6.6 user manual
-
-<sect2 id="linear-implicit-parameters">
-<title>Linear implicit parameters</title>
-<para>
-Linear implicit parameters are an idea developed by Koen Claessen,
-Mark Shields, and Simon PJ.  They address the long-standing
-problem that monads seem over-kill for certain sorts of problem, notably:
-</para>
-<itemizedlist>
-<listitem> <para> distributing a supply of unique names </para> </listitem>
-<listitem> <para> distributing a supply of random numbers </para> </listitem>
-<listitem> <para> distributing an oracle (as in QuickCheck) </para> </listitem>
-</itemizedlist>
-
-<para>
-Linear implicit parameters are just like ordinary implicit parameters,
-except that they are "linear"; that is, they cannot be copied, and
-must be explicitly "split" instead.  Linear implicit parameters are
-written '<literal>%x</literal>' instead of '<literal>?x</literal>'.
-(The '/' in the '%' suggests the split!)
-</para>
-<para>
-For example:
-<programlisting>
-    import GHC.Exts( Splittable )
-
-    data NameSupply = ...
-
-    splitNS :: NameSupply -> (NameSupply, NameSupply)
-    newName :: NameSupply -> Name
-
-    instance Splittable NameSupply where
-       split = splitNS
-
-
-    f :: (%ns :: NameSupply) => Env -> Expr -> Expr
-    f env (Lam x e) = Lam x' (f env e)
-                   where
-                     x'   = newName %ns
-                     env' = extend env x x'
-    ...more equations for f...
-</programlisting>
-Notice that the implicit parameter %ns is consumed
-<itemizedlist>
-<listitem> <para> once by the call to <literal>newName</literal> </para> 
</listitem>
-<listitem> <para> once by the recursive call to <literal>f</literal> 
</para></listitem>
-</itemizedlist>
-</para>
-<para>
-So the translation done by the type checker makes
-the parameter explicit:
-<programlisting>
-    f :: NameSupply -> Env -> Expr -> Expr
-    f ns env (Lam x e) = Lam x' (f ns1 env e)
-                      where
-                        (ns1,ns2) = splitNS ns
-                        x' = newName ns2
-                        env = extend env x x'
-</programlisting>
-Notice the call to 'split' introduced by the type checker.
-How did it know to use 'splitNS'?  Because what it really did
-was to introduce a call to the overloaded function 'split',
-defined by the class <literal>Splittable</literal>:
-<programlisting>
-       class Splittable a where
-         split :: a -> (a,a)
-</programlisting>
-The instance for <literal>Splittable NameSupply</literal> tells GHC how to 
implement
-split for name supplies.  But we can simply write
-<programlisting>
-       g x = (x, %ns, %ns)
-</programlisting>
-and GHC will infer
-<programlisting>
-       g :: (Splittable a, %ns :: a) => b -> (b,a,a)
-</programlisting>
-The <literal>Splittable</literal> class is built into GHC.  It's exported by 
module
-<literal>GHC.Exts</literal>.
-</para>
-<para>
-Other points:
-<itemizedlist>
-<listitem> <para> '<literal>?x</literal>' and '<literal>%x</literal>'
-are entirely distinct implicit parameters: you
-  can use them together and they won't interfere with each other. </para>
-</listitem>
-
-<listitem> <para> You can bind linear implicit parameters in 'with' clauses. 
</para> </listitem>
-
-<listitem> <para>You cannot have implicit parameters (whether linear or not)
-  in the context of a class or instance declaration. </para></listitem>
-</itemizedlist>
-</para>
-
-<sect3><title>Warnings</title>
-
-<para>
-The monomorphism restriction is even more important than usual.
-Consider the example above:
-<programlisting>
-    f :: (%ns :: NameSupply) => Env -> Expr -> Expr
-    f env (Lam x e) = Lam x' (f env e)
-                   where
-                     x'   = newName %ns
-                     env' = extend env x x'
-</programlisting>
-If we replaced the two occurrences of x' by (newName %ns), which is
-usually a harmless thing to do, we get:
-<programlisting>
-    f :: (%ns :: NameSupply) => Env -> Expr -> Expr
-    f env (Lam x e) = Lam (newName %ns) (f env e)
-                   where
-                     env' = extend env x (newName %ns)
-</programlisting>
-But now the name supply is consumed in <emphasis>three</emphasis> places
-(the two calls to newName,and the recursive call to f), so
-the result is utterly different.  Urk!  We don't even have
-the beta rule.
-</para>
-<para>
-Well, this is an experimental change.  With implicit
-parameters we have already lost beta reduction anyway, and
-(as John Launchbury puts it) we can't sensibly reason about
-Haskell programs without knowing their typing.
-</para>
-
-</sect3>
-
-<sect3><title>Recursive functions</title>
-<para>Linear implicit parameters can be particularly tricky when you have a 
recursive function
-Consider
-<programlisting>
-        foo :: %x::T => Int -> [Int]
-        foo 0 = []
-        foo n = %x : foo (n-1)
-</programlisting>
-where T is some type in class Splittable.</para>
-<para>
-Do you get a list of all the same T's or all different T's
-(assuming that split gives two distinct T's back)?
-</para><para>
-If you supply the type signature, taking advantage of polymorphic
-recursion, you get what you'd probably expect.  Here's the
-translated term, where the implicit param is made explicit:
-<programlisting>
-        foo x 0 = []
-        foo x n = let (x1,x2) = split x
-                  in x1 : foo x2 (n-1)
-</programlisting>
-But if you don't supply a type signature, GHC uses the Hindley
-Milner trick of using a single monomorphic instance of the function
-for the recursive calls. That is what makes Hindley Milner type inference
-work.  So the translation becomes
-<programlisting>
-        foo x = let
-                  foom 0 = []
-                  foom n = x : foom (n-1)
-                in
-                foom
-</programlisting>
-Result: 'x' is not split, and you get a list of identical T's.  So the
-semantics of the program depends on whether or not foo has a type signature.
-Yikes!
-</para><para>
-You may say that this is a good reason to dislike linear implicit parameters
-and you'd be right.  That is why they are an experimental feature.
-</para>
-</sect3>
-
-</sect2>
-
-================ END OF Linear Implicit Parameters commented out -->
-
 <sect2 id="kinding">
 <title>Explicitly-kinded quantification</title>
 
@@ -6822,9 +6645,6 @@ it becomes possible to do so.
 <para>Lexically-scoped type variables are enabled by
 <option>-XScopedTypeVariables</option>.  This flag implies 
<option>-XRelaxedPolyRec</option>.
 </para>
-<para>Note: GHC 6.6 contains substantial changes to the way that scoped type
-variables work, compared to earlier releases.  Read this section
-carefully!</para>
 
 <sect3>
 <title>Overview</title>



_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to