Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master
http://hackage.haskell.org/trac/ghc/changeset/114cfc073cb9741cfcf79209c0e6053e8ee72ff4 >--------------------------------------------------------------- commit 114cfc073cb9741cfcf79209c0e6053e8ee72ff4 Author: Daniel Fischer <[email protected]> Date: Thu Nov 24 16:56:01 2011 +0100 Fix a few typos >--------------------------------------------------------------- docs/users_guide/glasgow_exts.xml | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml index 3b2ad21..09dd782 100644 --- a/docs/users_guide/glasgow_exts.xml +++ b/docs/users_guide/glasgow_exts.xml @@ -933,7 +933,7 @@ rec { b <- f a c ===> (b,c) <- mfix (\~(b,c) -> do { b <- f a c ; c <- f b a } ; c <- f b a ; return (b,c) }) </programlisting> -In general, the statment <literal>rec <replaceable>ss</replaceable></literal> +In general, the statement <literal>rec <replaceable>ss</replaceable></literal> is desugared to the statement <programlisting> <replaceable>vs</replaceable> <- mfix (\~<replaceable>vs</replaceable> -> do { <replaceable>ss</replaceable>; return <replaceable>vs</replaceable> }) @@ -1028,7 +1028,7 @@ This name is not supported by GHC. [ (x, y) | x <- xs | y <- ys ] </programlisting> - <para>The behavior of parallel list comprehensions follows that of + <para>The behaviour of parallel list comprehensions follows that of zip, in that the resulting list will have the same length as the shortest branch.</para> @@ -4260,7 +4260,7 @@ of the instance declaration, thus: </para> <para> Warning: overlapping instances must be used with care. They -can give rise to incoherence (ie different instance choices are made +can give rise to incoherence (i.e. different instance choices are made in different parts of the program) even without <option>-XIncoherentInstances</option>. Consider: <programlisting> {-# LANGUAGE OverlappingInstances #-} @@ -4974,7 +4974,7 @@ class GMapKey k where instance (GMapKey a, GMapKey b) => GMapKey (Either a b) where data GMap (Either a b) v = GMapEither (GMap a v) (GMap b v) - ...method declartions... + ...method declarations... </programlisting> Here are some export lists and their meaning: <itemizedlist> @@ -4992,7 +4992,7 @@ Here are some export lists and their meaning: </listitem> <listitem> <para><literal>module GMap( GMapKey( type GMap, empty, lookup, insert ) )</literal>: - Same as the pevious item. Note the "<literal>type</literal>" keyword.</para> + Same as the previous item. Note the "<literal>type</literal>" keyword.</para> </listitem> <listitem> <para><literal>module GMap( GMapKey(..), GMap(..) )</literal>: @@ -5029,7 +5029,7 @@ Two things to watch out for: import X data instance D Int = D1 | D2 </programlisting> - Module Y exports all the entities defined in Y, namely the data constructrs <literal>D1</literal> + Module Y exports all the entities defined in Y, namely the data constructors <literal>D1</literal> and <literal>D2</literal>, <emphasis>but not the data family <literal>D</literal></emphasis>. That (annoyingly) means that you cannot selectively import Y selectively, thus "<literal>import Y( D(D1,D2) )</literal>", because Y does not export <literal>D</literal>. @@ -8327,7 +8327,7 @@ happen. <listitem> <para>You can add phase control (<xref linkend="phase-control"/>) to the RULE generated by a <literal>SPECIALIZE</literal> pragma, - just as you can if you writ a RULE directly. For exxample: + just as you can if you write a RULE directly. For example: <programlisting> {-# SPECIALIZE [0] hammeredLookup :: [(Widget, value)] -> Widget -> value #-} </programlisting> @@ -8342,12 +8342,12 @@ happen. {-# SPECIALIZE foo :: Int -> Int #-} </programlisting> The <literal>NOINLINE</literal> pragma tells GHC not to inline <literal>foo</literal> - until Phase 0; and this property is inherited by the specialiation RULE, which will + until Phase 0; and this property is inherited by the specialisation RULE, which will therefore only fire in Phase 0.</para> <para>The main reason for using phase control on specialisations is so that you can write optimisation RULES that fire early in the compilation pipeline, and only <emphasis>then</emphasis> specialise the calls to the function. If specialisation is - done too early, the optimsation rules might fail to fire. + done too early, the optimisation rules might fail to fire. </para> </listitem> _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
