X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fglasgow_exts.xml;h=4f022395872fc81bc31e2e242cb73b22c68800f5;hb=ba00f074b38f4e168c893adc293c5b9cd6992721;hp=b1e9c3127296a53b15563143520271b46c4a3688;hpb=a975e8341a53ec9cef25af816a9bf9ce96c16391;p=ghc-hetmet.git
diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index b1e9c31..4f02239 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -1152,16 +1152,16 @@ GHC allows a small extension to the syntax of left operator sections, which
allows you to define postfix operators. The extension is this: the left section
(e !)
-
+
is equivalent (from the point of view of both type checking and execution) to the expression
((!) e)
-
+
(for any expression e and operator (!).
The strict Haskell 98 interpretation is that the section is equivalent to
(\y -> (!) e y)
-
+
That is, the operator must be a function of two arguments. GHC allows it to
take only one argument, and that in turn allows you to write the function
postfix.
@@ -2388,14 +2388,14 @@ Haskell 98, you can inherit instances of Eq, Ord
+
newtype Dollars = Dollars Int
-
+
and you want to use arithmetic on Dollars, you have to
explicitly define an instance of Num:
-
+
instance Num Dollars where
Dollars a + Dollars b = Dollars (a+b)
...
@@ -2413,17 +2413,17 @@ dictionary, only slower!
GHC now permits such instances to be derived instead,
using the flag ,
so one can write
-
+
newtype Dollars = Dollars Int deriving (Eq,Show,Num)
-
+
and the implementation uses the sameNum dictionary
for Dollars as for Int. Notionally, the compiler
derives an instance declaration of the form
-
+
instance Num Int => Num Dollars
-
+
which just adds or removes the newtype constructor according to the type.
@@ -2433,27 +2433,27 @@ We can also derive instances of constructor classes in a similar
way. For example, suppose we have implemented state and failure monad
transformers, such that
-
+
instance Monad m => Monad (State s m)
instance Monad m => Monad (Failure m)
-
+
In Haskell 98, we can define a parsing monad by
-
+
type Parser tok m a = State [tok] (Failure m) a
-
+
which is automatically a monad thanks to the instance declarations
above. With the extension, we can make the parser type abstract,
without needing to write an instance of class Monad, via
-
+
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving Monad
In this case the derived instance declaration is of the form
-
+
instance Monad (State [tok] (Failure m)) => Monad (Parser tok m)
-
+
Notice that, since Monad is a constructor class, the
instance is a partial application of the new type, not the
@@ -2468,12 +2468,12 @@ newtype is the last class parameter. In this case, a ``partial
application'' of the class appears in the deriving
clause. For example, given the class
-
+
class StateMonad s m | m -> s where ...
instance Monad m => StateMonad s (State s m) where ...
-
+
then we can derive an instance of StateMonad for Parsers by
-
+
newtype Parser tok m a = Parser (State [tok] (Failure m) a)
deriving (Monad, StateMonad [tok])
@@ -2481,7 +2481,7 @@ then we can derive an instance of StateMonad for Par
The derived instance is obtained by completing the application of the
class to the new type:
-
+
instance StateMonad [tok] (State [tok] (Failure m)) =>
StateMonad [tok] (Parser tok m)
@@ -2501,9 +2501,9 @@ the newtype and its representation.
Derived instance declarations are constructed as follows. Consider the
declaration (after expansion of any type synonyms)
-
+
newtype T v1...vn = T' (t vk+1...vn) deriving (c1...cm)
-
+
where
@@ -2532,17 +2532,17 @@ where
Then, for each ci, the derived instance
declaration is:
-
+
instance ci t => ci (T v1...vk)
As an example which does not work, consider
-
+
newtype NonMonad m s = NonMonad (State s m s) deriving Monad
-
+
Here we cannot derive the instance
-
+
instance Monad (State s m) => Monad (NonMonad m)
-
+
because the type variable s occurs in State s m,
and so cannot be "eta-converted" away. It is a good thing that this
@@ -2556,7 +2556,7 @@ Notice also that the order of class parameters becomes
important, since we can only derive instances for the last one. If the
StateMonad class above were instead defined as
-
+
class StateMonad m s | m -> s where ...
@@ -3144,7 +3144,7 @@ typechecker loop:
class F a b | a->b
instance F [a] [[a]]
instance (D c, F a c) => D [a] -- 'c' is not mentioned in the head
-
+
Similarly, it can be tempting to lift the coverage condition:
class Mul a b c | a b -> c where
@@ -4450,7 +4450,7 @@ type variable s into scope, in the annotated expression
Pattern type signatures
A type signature may occur in any pattern; this is a pattern type
-signature.
+signature.
For example:
-- f and g assume that 'a' is already in scope
@@ -4463,9 +4463,27 @@ already in scope (i.e. bound by the enclosing context), matters are simple: the
signature simply constrains the type of the pattern in the obvious way.
-There is only one situation in which you can write a pattern type signature that
-mentions a type variable that is not already in scope, namely in pattern match
-of an existential data constructor. For example:
+Unlike expression and declaration type signatures, pattern type signatures are not implictly generalised.
+The pattern in a patterm binding may only mention type variables
+that are already in scope. For example:
+
+ f :: forall a. [a] -> (Int, [a])
+ f xs = (n, zs)
+ where
+ (ys::[a], n) = (reverse xs, length xs) -- OK
+ zs::[a] = xs ++ ys -- OK
+
+ Just (v::b) = ... -- Not OK; b is not in scope
+
+Here, the pattern signatures for ys and zs
+are fine, but the one for v is not because b is
+not in scope.
+
+
+However, in all patterns other than pattern bindings, a pattern
+type signature may mention a type variable that is not in scope; in this case,
+the signature brings that type variable into scope.
+This is particularly important for existential data constructors. For example:
data T = forall a. MkT [a]
@@ -4475,14 +4493,19 @@ of an existential data constructor. For example:
t3::[a] = [t,t,t]
Here, the pattern type signature (t::a) mentions a lexical type
-variable that is not already in scope. Indeed, it cannot already be in scope,
+variable that is not already in scope. Indeed, it cannot already be in scope,
because it is bound by the pattern match. GHC's rule is that in this situation
(and only then), a pattern type signature can mention a type variable that is
not already in scope; the effect is to bring it into scope, standing for the
existentially-bound type variable.
-If this seems a little odd, we think so too. But we must have
+When a pattern type signature binds a type variable in this way, GHC insists that the
+type variable is bound to a rigid, or fully-known, type variable.
+This means that any user-written type signature always stands for a completely known type.
+
+
+If all this seems a little odd, we think so too. But we must have
some way to bring such type variables into scope, else we
could not name existentially-bound type variables in subsequent type signatures.
@@ -5835,8 +5858,26 @@ key_function :: Int -> String -> (Bool, Double)
The major effect of an INLINE pragma
is to declare a function's “cost” to be very low.
The normal unfolding machinery will then be very keen to
- inline it.
-
+ inline it. However, an INLINE pragma for a
+ function "f" has a number of other effects:
+
+
+No funtions are inlined into f. Otherwise
+GHC might inline a big function into f's right hand side,
+making f big; and then inline f blindly.
+
+
+The float-in, float-out, and common-sub-expression transformations are not
+applied to the body of f.
+
+
+An INLINE function is not worker/wrappered by strictness analysis.
+It's going to be inlined wholesale instead.
+
+
+All of these effects are aimed at ensuring that what gets inlined is
+exactly what you asked for, no more and no less.
+
Syntactically, an INLINE pragma for a
function can be put anywhere its type signature could be
put.
@@ -6024,7 +6065,7 @@ happen.
h :: Eq a => a -> a -> a
{-# SPECIALISE h :: (Eq a) => [a] -> [a] -> [a] #-}
-
+
The last of these examples will generate a
RULE with a somewhat-complex left-hand side (try it yourself), so it might not fire very
well. If you use this kind of specialisation, let us know how well it works.