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
