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, 16 months ago)
  • docs/users_guide/glasgow_exts.xml

    From 2fbf2d6a47f01ebf0f5faff8fdc26c9f7b9ada6a Mon Sep 17 00:00:00 2001
    From: Ben Millwood <thebenmachine+git@gmail.com>
    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>