Ticket #7533: 0001-Remove-references-to-GHC-6.6-in-docs.patch

File 0001-Remove-references-to-GHC-6.6-in-docs.patch, 7.2 KB (added by benmachine, 3 years ago)
  • docs/users_guide/glasgow_exts.xml

    From 2fbf2d6a47f01ebf0f5faff8fdc26c9f7b9ada6a Mon Sep 17 00:00:00 2001
    From: Ben Millwood <[email protected]>
    Date: Wed, 26 Dec 2012 23:24:49 +0000
    Subject: [PATCH] Remove references to GHC 6.6 in docs
    
    ---
     docs/users_guide/glasgow_exts.xml | 180 --------------------------------------
     1 file changed, 180 deletions(-)
    
    diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
    index 433aa8f..93279aa 100644
    a b inner binding of <literal>?x</literal>, so <literal>(f 9)</literal> will return 
    62346234</sect3>
    62356235</sect2>
    62366236
    6237     <!--   ======================= COMMENTED OUT ========================
    6238 
    6239     We intend to remove linear implicit parameters, so I'm at least removing
    6240     them from the 6.6 user manual
    6241 
    6242 <sect2 id="linear-implicit-parameters">
    6243 <title>Linear implicit parameters</title>
    6244 <para>
    6245 Linear implicit parameters are an idea developed by Koen Claessen,
    6246 Mark Shields, and Simon PJ.  They address the long-standing
    6247 problem that monads seem over-kill for certain sorts of problem, notably:
    6248 </para>
    6249 <itemizedlist>
    6250 <listitem> <para> distributing a supply of unique names </para> </listitem>
    6251 <listitem> <para> distributing a supply of random numbers </para> </listitem>
    6252 <listitem> <para> distributing an oracle (as in QuickCheck) </para> </listitem>
    6253 </itemizedlist>
    6254 
    6255 <para>
    6256 Linear implicit parameters are just like ordinary implicit parameters,
    6257 except that they are "linear"; that is, they cannot be copied, and
    6258 must be explicitly "split" instead.  Linear implicit parameters are
    6259 written '<literal>%x</literal>' instead of '<literal>?x</literal>'.
    6260 (The '/' in the '%' suggests the split!)
    6261 </para>
    6262 <para>
    6263 For example:
    6264 <programlisting>
    6265     import GHC.Exts( Splittable )
    6266 
    6267     data NameSupply = ...
    6268 
    6269     splitNS :: NameSupply -> (NameSupply, NameSupply)
    6270     newName :: NameSupply -> Name
    6271 
    6272     instance Splittable NameSupply where
    6273         split = splitNS
    6274 
    6275 
    6276     f :: (%ns :: NameSupply) => Env -> Expr -> Expr
    6277     f env (Lam x e) = Lam x' (f env e)
    6278                     where
    6279                       x'   = newName %ns
    6280                       env' = extend env x x'
    6281     ...more equations for f...
    6282 </programlisting>
    6283 Notice that the implicit parameter %ns is consumed
    6284 <itemizedlist>
    6285 <listitem> <para> once by the call to <literal>newName</literal> </para> </listitem>
    6286 <listitem> <para> once by the recursive call to <literal>f</literal> </para></listitem>
    6287 </itemizedlist>
    6288 </para>
    6289 <para>
    6290 So the translation done by the type checker makes
    6291 the parameter explicit:
    6292 <programlisting>
    6293     f :: NameSupply -> Env -> Expr -> Expr
    6294     f ns env (Lam x e) = Lam x' (f ns1 env e)
    6295                        where
    6296                          (ns1,ns2) = splitNS ns
    6297                          x' = newName ns2
    6298                          env = extend env x x'
    6299 </programlisting>
    6300 Notice the call to 'split' introduced by the type checker.
    6301 How did it know to use 'splitNS'?  Because what it really did
    6302 was to introduce a call to the overloaded function 'split',
    6303 defined by the class <literal>Splittable</literal>:
    6304 <programlisting>
    6305         class Splittable a where
    6306           split :: a -> (a,a)
    6307 </programlisting>
    6308 The instance for <literal>Splittable NameSupply</literal> tells GHC how to implement
    6309 split for name supplies.  But we can simply write
    6310 <programlisting>
    6311         g x = (x, %ns, %ns)
    6312 </programlisting>
    6313 and GHC will infer
    6314 <programlisting>
    6315         g :: (Splittable a, %ns :: a) => b -> (b,a,a)
    6316 </programlisting>
    6317 The <literal>Splittable</literal> class is built into GHC.  It's exported by module
    6318 <literal>GHC.Exts</literal>.
    6319 </para>
    6320 <para>
    6321 Other points:
    6322 <itemizedlist>
    6323 <listitem> <para> '<literal>?x</literal>' and '<literal>%x</literal>'
    6324 are entirely distinct implicit parameters: you
    6325   can use them together and they won't interfere with each other. </para>
    6326 </listitem>
    6327 
    6328 <listitem> <para> You can bind linear implicit parameters in 'with' clauses. </para> </listitem>
    6329 
    6330 <listitem> <para>You cannot have implicit parameters (whether linear or not)
    6331   in the context of a class or instance declaration. </para></listitem>
    6332 </itemizedlist>
    6333 </para>
    6334 
    6335 <sect3><title>Warnings</title>
    6336 
    6337 <para>
    6338 The monomorphism restriction is even more important than usual.
    6339 Consider the example above:
    6340 <programlisting>
    6341     f :: (%ns :: NameSupply) => Env -> Expr -> Expr
    6342     f env (Lam x e) = Lam x' (f env e)
    6343                     where
    6344                       x'   = newName %ns
    6345                       env' = extend env x x'
    6346 </programlisting>
    6347 If we replaced the two occurrences of x' by (newName %ns), which is
    6348 usually a harmless thing to do, we get:
    6349 <programlisting>
    6350     f :: (%ns :: NameSupply) => Env -> Expr -> Expr
    6351     f env (Lam x e) = Lam (newName %ns) (f env e)
    6352                     where
    6353                       env' = extend env x (newName %ns)
    6354 </programlisting>
    6355 But now the name supply is consumed in <emphasis>three</emphasis> places
    6356 (the two calls to newName,and the recursive call to f), so
    6357 the result is utterly different.  Urk!  We don't even have
    6358 the beta rule.
    6359 </para>
    6360 <para>
    6361 Well, this is an experimental change.  With implicit
    6362 parameters we have already lost beta reduction anyway, and
    6363 (as John Launchbury puts it) we can't sensibly reason about
    6364 Haskell programs without knowing their typing.
    6365 </para>
    6366 
    6367 </sect3>
    6368 
    6369 <sect3><title>Recursive functions</title>
    6370 <para>Linear implicit parameters can be particularly tricky when you have a recursive function
    6371 Consider
    6372 <programlisting>
    6373         foo :: %x::T => Int -> [Int]
    6374         foo 0 = []
    6375         foo n = %x : foo (n-1)
    6376 </programlisting>
    6377 where T is some type in class Splittable.</para>
    6378 <para>
    6379 Do you get a list of all the same T's or all different T's
    6380 (assuming that split gives two distinct T's back)?
    6381 </para><para>
    6382 If you supply the type signature, taking advantage of polymorphic
    6383 recursion, you get what you'd probably expect.  Here's the
    6384 translated term, where the implicit param is made explicit:
    6385 <programlisting>
    6386         foo x 0 = []
    6387         foo x n = let (x1,x2) = split x
    6388                   in x1 : foo x2 (n-1)
    6389 </programlisting>
    6390 But if you don't supply a type signature, GHC uses the Hindley
    6391 Milner trick of using a single monomorphic instance of the function
    6392 for the recursive calls. That is what makes Hindley Milner type inference
    6393 work.  So the translation becomes
    6394 <programlisting>
    6395         foo x = let
    6396                   foom 0 = []
    6397                   foom n = x : foom (n-1)
    6398                 in
    6399                 foom
    6400 </programlisting>
    6401 Result: 'x' is not split, and you get a list of identical T's.  So the
    6402 semantics of the program depends on whether or not foo has a type signature.
    6403 Yikes!
    6404 </para><para>
    6405 You may say that this is a good reason to dislike linear implicit parameters
    6406 and you'd be right.  That is why they are an experimental feature.
    6407 </para>
    6408 </sect3>
    6409 
    6410 </sect2>
    6411 
    6412 ================ END OF Linear Implicit Parameters commented out -->
    6413 
    64146237<sect2 id="kinding">
    64156238<title>Explicitly-kinded quantification</title>
    64166239
    it becomes possible to do so. 
    68226645<para>Lexically-scoped type variables are enabled by
    68236646<option>-XScopedTypeVariables</option>.  This flag implies <option>-XRelaxedPolyRec</option>.
    68246647</para>
    6825 <para>Note: GHC 6.6 contains substantial changes to the way that scoped type
    6826 variables work, compared to earlier releases.  Read this section
    6827 carefully!</para>
    68286648
    68296649<sect3>
    68306650<title>Overview</title>