X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;ds=sidebyside;f=docs%2Fusers_guide%2Fglasgow_exts.xml;h=d60e8e939e2491ff1f491e8cfd1a0a7bf9ba414c;hb=8c86756116f7142f0b6f6d1e9f5e1d55fa1cb0d1;hp=beaaad616a393caf66fc20809d502363266087fb;hpb=0065d5ab628975892cea1ec7303f968c3338cbe1;p=ghc-hetmet.git
diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index beaaad6..d60e8e9 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -116,11 +116,22 @@ documentation describes all the libraries that come with GHC.
- :
-
+ ,:
+
+
+ These two flags control how generalisation is done.
+ See .
+
+
+
+
+
+
+ :
+
- Switch off the Haskell 98 monomorphism restriction.
+ Use GHCi's extended default rules in a regular module ().
Independent of the
flag.
@@ -140,7 +151,7 @@ documentation describes all the libraries that come with GHC.
-
+
@@ -244,7 +255,8 @@ documentation describes all the libraries that come with GHC.
Enables Template Haskell (see ). Currently also implied by
+ linkend="template-haskell"/>). This flag must
+ be given explicitly; it is no longer implied by
.Syntax stolen: [|,
@@ -616,7 +628,7 @@ clunky env var1 var1 = case lookup env var1 of
Nothing -> fail
Just val2 -> val1 + val2
where
- fail = val1 + val2
+ fail = var1 + var2
@@ -1009,8 +1021,8 @@ in a type synonym, thus:
f :: Discard a
f x y = (x, show y)
- g :: Discard Int -> (Int,Bool) -- A rank-2 type
- g f = f Int True
+ g :: Discard Int -> (Int,String) -- A rank-2 type
+ g f = f 3 True
@@ -2021,6 +2033,11 @@ something more specific does not:
op = ... -- Default
+You can find lots of background material about the reason for these
+restrictions in the paper
+Understanding functional dependencies via Constraint Handling Rules.
+
@@ -2089,7 +2106,7 @@ option, you can use arbitrary
types in both an instance context and instance head. Termination is ensured by having a
fixed-depth recursion stack. If you exceed the stack depth you get a
sort of backtrace, and the opportunity to increase the stack depth
-with N.
+with N.
@@ -2106,7 +2123,9 @@ can be modified by two flags:
and
-fallow-incoherent-instances
-, as this section discusses.
+, as this section discusses. Both these
+flags are dynamic flags, and can be set on a per-module basis, using
+an OPTIONS_GHC pragma if desired ().
When GHC tries to resolve, say, the constraint C Int Bool,
it tries to match every instance declaration against the
@@ -2175,8 +2194,20 @@ some other constraint. But if the instance declaration was compiled with
check for that declaration.
-All this makes it possible for a library author to design a library that relies on
-overlapping instances without the library client having to know.
+These rules make it possible for a library author to design a library that relies on
+overlapping instances without the library client having to know.
+
+
+If an instance declaration is compiled without
+,
+then that instance can never be overlapped. This could perhaps be
+inconvenient. Perhaps the rule should instead say that the
+overlapping instance declaration should be compiled in
+this way, rather than the overlapped one. Perhaps overlap
+at a usage site should be permitted regardless of how the instance declarations
+are compiled, if the flag is
+used at the usage site. (Mind you, the exact usage site can occasionally be
+hard to pin down.) We are interested to receive feedback on these points.
The flag implies the
flag, but not vice versa.
@@ -2463,7 +2494,7 @@ function that called it. For example, our sort function might
to pick out the least value in a list:
least :: (?cmp :: a -> a -> Bool) => [a] -> a
- least xs = fst (sort xs)
+ least xs = head (sort xs)
Without lifting a finger, the ?cmp parameter is
propagated to become a parameter of least as well. With explicit
@@ -2623,6 +2654,11 @@ inner binding of ?x, so (f 9) will return
+
+
Explicitly-kinded quantification
@@ -3160,228 +3198,102 @@ for rank-2 types.
-
+
+Impredicative polymorphism
+
+GHC supports impredicative polymorphism. This means
+that you can call a polymorphic function at a polymorphic type, and
+parameterise data structures over polymorphic types. For example:
+
+ f :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char])
+ f (Just g) = Just (g [3], g "hello")
+ f Nothing = Nothing
+
+Notice here that the Maybe type is parameterised by the
+polymorphic type (forall a. [a] ->
+[a]).
+
+The technical details of this extension are described in the paper
+Boxy types:
+type inference for higher-rank types and impredicativity,
+which appeared at ICFP 2006.
+
+
-Scoped type variables
+Lexically scoped type variables
-A lexically scoped type variable can be bound by:
-
-A declaration type signature ()
-A pattern type signature ()
-A result type signature ()
-
-For example:
+GHC supports lexically scoped type variables, without
+which some type signatures are simply impossible to write. For example:
-f (xs::[a]) = ys ++ ys
- where
- ys :: [a]
- ys = reverse xs
+f :: forall a. [a] -> [a]
+f xs = ys ++ ys
+ where
+ ys :: [a]
+ ys = reverse xs
-The pattern (xs::[a]) includes a type signature for xs.
-This brings the type variable a into scope; it scopes over
-all the patterns and right hand sides for this equation for f.
-In particular, it is in scope at the type signature for y.
-
-
-
-At ordinary type signatures, such as that for ys, any type variables
-mentioned in the type signature that are not in scope are
-implicitly universally quantified. (If there are no type variables in
-scope, all type variables mentioned in the signature are universally
-quantified, which is just as in Haskell 98.) In this case, since a
-is in scope, it is not universally quantified, so the type of ys is
-the same as that of xs. In Haskell 98 it is not possible to declare
+The type signature for f brings the type variable a into scope; it scopes over
+the entire definition of f.
+In particular, it is in scope at the type signature for ys.
+In Haskell 98 it is not possible to declare
a type for ys; a major benefit of scoped type variables is that
it becomes possible to do so.
-
-
-Scoped type variables are implemented in both GHC and Hugs. Where the
-implementations differ from the specification below, those differences
-are noted.
-
-
-
-So much for the basic idea. Here are the details.
+Lexically-scoped type variables are enabled by
+.
+Note: GHC 6.6 contains substantial changes to the way that scoped type
+variables work, compared to earlier releases. Read this section
+carefully!
-What a scoped type variable means
-
-A lexically-scoped type variable is simply
-the name for a type. The restriction it expresses is that all occurrences
-of the same name mean the same type. For example:
-
- f :: [Int] -> Int -> Int
- f (xs::[a]) (y::a) = (head xs + y) :: a
-
-The pattern type signatures on the left hand side of
-f express the fact that xs
-must be a list of things of some type a; and that y
-must have this same type. The type signature on the expression (head xs)
-specifies that this expression must have the same type a.
-There is no requirement that the type named by "a" is
-in fact a type variable. Indeed, in this case, the type named by "a" is
-Int. (This is a slight liberalisation from the original rather complex
-rules, which specified that a pattern-bound type variable should be universally quantified.)
-For example, all of these are legal:
-
-
- t (x::a) (y::a) = x+y*2
-
- f (x::a) (y::b) = [x,y] -- a unifies with b
-
- g (x::a) = x + 1::Int -- a unifies with Int
-
- h x = let k (y::a) = [x,y] -- a is free in the
- in k x -- environment
-
- k (x::a) True = ... -- a unifies with Int
- k (x::Int) False = ...
-
- w :: [b] -> [b]
- w (x::a) = x -- a unifies with [b]
-
-
-
-
-
-Scope and implicit quantification
-
-
+Overview
+The design follows the following principles
-
-
-
-All the type variables mentioned in a pattern,
-that are not already in scope,
-are brought into scope by the pattern. We describe this set as
-the type variables bound by the pattern.
-For example:
-
- f (x::a) = let g (y::(a,b)) = fst y
- in
- g (x,True)
-
-The pattern (x::a) brings the type variable
-a into scope, as well as the term
-variable x. The pattern (y::(a,b))
-contains an occurrence of the already-in-scope type variable a,
-and brings into scope the type variable b.
-
-
-
-
-
-The type variable(s) bound by the pattern have the same scope
-as the term variable(s) bound by the pattern. For example:
-
- let
- f (x::a) = <...rhs of f...>
- (p::b, q::b) = (1,2)
- in <...body of let...>
-
-Here, the type variable a scopes over the right hand side of f,
-just like x does; while the type variable b scopes over the
-body of the let, and all the other definitions in the let,
-just like p and q do.
-Indeed, the newly bound type variables also scope over any ordinary, separate
-type signatures in the let group.
-
-
-
-
-
-
-The type variables bound by the pattern may be
-mentioned in ordinary type signatures or pattern
-type signatures anywhere within their scope.
-
-
-
-
-
-
- In ordinary type signatures, any type variable mentioned in the
-signature that is in scope is not universally quantified.
-
-
-
-
-
-
-
- Ordinary type signatures do not bring any new type variables
-into scope (except in the type signature itself!). So this is illegal:
-
-
- f :: a -> a
- f x = x::a
-
-
-It's illegal because a is not in scope in the body of f,
-so the ordinary signature x::a is equivalent to x::forall a.a;
-and that is an incorrect typing.
-
+A scoped type variable stands for a type variable, and not for
+a type. (This is a change from GHC's earlier
+design.)
+Furthermore, distinct lexical type variables stand for distinct
+type variables. This means that every programmer-written type signature
+(includin one that contains free scoped type variables) denotes a
+rigid type; that is, the type is fully known to the type
+checker, and no inference is involved.
+Lexical type variables may be alpha-renamed freely, without
+changing the program.
+
-
-
-
-The pattern type signature is a monotype:
-
-
+A lexically scoped type variable can be bound by:
-
-A pattern type signature cannot contain any explicit forall quantification.
-
-
-
-The type variables bound by a pattern type signature can only be instantiated to monotypes,
-not to type schemes.
-
-
-
-There is no implicit universal quantification on pattern type signatures (in contrast to
-ordinary type signatures).
-
-
+A declaration type signature ()
+A pattern type signature ()
+Class and instance declarations ()
-
-
-
-
+
-
-The type variables in the head of a class or instance declaration
-scope over the methods defined in the where part. For example:
-
-
+In Haskell, a programmer-written type signature is implicitly quantifed over
+its free type variables (Section
+4.1.2
+of the Haskel Report).
+Lexically scoped type variables affect this implicit quantification rules
+as follows: any type variable that is in scope is not universally
+quantified. For example, if type variable a is in scope,
+then
- class C a where
- op :: [a] -> a
-
- op xs = let ys::[a]
- ys = reverse xs
- in
- head ys
+ (e :: a -> a) means (e :: a -> a)
+ (e :: b -> b) means (e :: forall b. b->b)
+ (e :: a -> b) means (e :: forall b. a->b)
-
-
-(Not implemented in Hugs yet, Dec 98).
-
-
-
-
+
Declaration type signaturesA declaration type signature that has explicit
@@ -3409,179 +3321,127 @@ quantification rules.
-Where a pattern type signature can occur
-
+Pattern type signatures
-A pattern type signature can occur in any pattern. For example:
-
-
-
-
-A pattern type signature can be on an arbitrary sub-pattern, not
-just on a variable:
-
-
+A type signature may occur in any pattern; this is a pattern type
+signature.
+For example:
- f ((x,y)::(a,b)) = (y,x) :: (b,a)
+ -- f and g assume that 'a' is already in scope
+ f = \(x::Int, y) -> x
+ g (x::a) = x
+ h ((x,y) :: (Int,Bool)) = (y,x)
-
-
+In the case where all the type variables in the pattern type sigature are
+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.
-
-
-
- Pattern type signatures, including the result part, can be used
-in lambda abstractions:
-
+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:
- (\ (x::a, y) :: a -> x)
+ data T = forall a. MkT [a]
+
+ k :: T -> T
+ k (MkT [t::a]) = MkT t3
+ where
+ 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,
+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.
-
-
-
- Pattern type signatures, including the result part, can be used
-in case expressions:
-
-
- case e of { ((x::a, y) :: (a,b)) -> x }
-
-
-Note that the -> symbol in a case alternative
-leads to difficulties when parsing a type signature in the pattern: in
-the absence of the extra parentheses in the example above, the parser
-would try to interpret the -> as a function
-arrow and give a parse error later.
-
+If 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 subequent type signatures.
-
-
-
-
-To avoid ambiguity, the type after the “::” in a result
-pattern signature on a lambda or case must be atomic (i.e. a single
-token or a parenthesised type of some sort). To see why,
-consider how one would parse this:
+This is (now) the only situation in which a pattern type
+signature is allowed to mention a lexical variable that is not already in
+scope.
+For example, both f and g would be
+illegal if a was not already in scope.
+
-
- \ x :: a -> b -> x
-
-
+
-
-
+
+
+Class and instance declarations
-The result type of a function can be given a signature, thus:
-
-
- f (x::a) :: [a] = [x,x,x]
-
-
-
-The final :: [a] after all the patterns gives a signature to the
-result type. Sometimes this is the only way of naming the type variable
-you want:
+The type variables in the head of a class or instance declaration
+scope over the methods defined in the where part. For example:
- f :: Int -> [a] -> [a]
- f n :: ([a] -> [a]) = let g (x::a, y::a) = (y,x)
- in \xs -> map g (reverse xs `zip` xs)
-
-
-
-
-The type variables bound in a result type signature scope over the right hand side
-of the definition. However, consider this corner-case:
-
- rev1 :: [a] -> [a] = \xs -> reverse xs
+ class C a where
+ op :: [a] -> a
- foo ys = rev (ys::[a])
-
-The signature on rev1 is considered a pattern type signature, not a result
-type signature, and the type variables it binds have the same scope as rev1
-itself (i.e. the right-hand side of rev1 and the rest of the module too).
-In particular, the expression (ys::[a]) is OK, because the type variable a
-is in scope (otherwise it would mean (ys::forall a.[a]), which would be rejected).
-
-
-As mentioned above, rev1 is made monomorphic by this scoping rule.
-For example, the following program would be rejected, because it claims that rev1
-is polymorphic:
-
- rev1 :: [b] -> [b]
- rev1 :: [a] -> [a] = \xs -> reverse xs
+ op xs = let ys::[a]
+ ys = reverse xs
+ in
+ head ys
-
-
-Result type signatures are not yet implemented in Hugs.
-
-
@@ -3742,20 +3602,17 @@ Derived instance declarations are constructed as follows. Consider the
declaration (after expansion of any type synonyms)
- newtype T v1...vn = T' (S t1...tk vk+1...vn) deriving (c1...cm)
+ newtype T v1...vn = T' (t vk+1...vn) deriving (c1...cm)
where
- S is a type constructor,
-
-
- The t1...tk are types,
+ The type t is an arbitrary type
- The vk+1...vn are type variables which do not occur in any of
- the ti, and
+ The vk+1...vn are type variables which do not occur in
+ t, and
The ci are partial applications of
@@ -3773,7 +3630,7 @@ where
Then, for each ci, the derived instance
declaration is:
- instance ci (S t1...tk vk+1...v) => ci (T v1...vp)
+ instance ci (t vk+1...v) => ci (T v1...vp)
where p is chosen so that T v1...vp is of the
right kind for the last parameter of class Ci.
@@ -3916,7 +3773,13 @@ for these Terms:
These and many other examples are given in papers by Hongwei Xi, and Tim Sheard.
- The extensions to GHC are these:
+
+The rest of this section outlines the extensions to GHC that support GADTs.
+It is far from comprehensive, but the design closely follows that described in
+the paper Simple
+unification-based type inference for GADTs,
+which appeared in ICFP 2006.
Data type declarations have a 'where' form, as exemplified above. The type signature of
@@ -4059,19 +3922,26 @@ the result type of the case expression. Hence the addition <
Template Haskell
-Template Haskell allows you to do compile-time meta-programming in Haskell. There is a "home page" for
-Template Haskell at
-http://www.haskell.org/th/, while
-the background to
+Template Haskell allows you to do compile-time meta-programming in
+Haskell.
+The background to
the main technical innovations is discussed in "
Template Meta-programming for Haskell" (Proc Haskell Workshop 2002).
-The details of the Template Haskell design are still in flux. Make sure you
-consult the online library reference material
+
+
+There is a Wiki page about
+Template Haskell at
+http://www.haskell.org/th/, and that is the best place to look for
+further details.
+You may also
+consult the online
+Haskell library reference material
(search for the type ExpQ).
[Temporary: many changes to the original design are described in
"http://research.microsoft.com/~simonpj/tmp/notes2.ps".
-Not all of these changes are in GHC 6.2.]
+Not all of these changes are in GHC 6.6.]
The first example from that paper is set out below as a worked example to help get you started.
@@ -4089,9 +3959,8 @@ Tim Sheard is going to expand it.)
constructions. You need to use the flag
to switch these syntactic extensions on
- ( is currently implied by
- , but you are encouraged to
- specify it explicitly).
+ ( is no longer implied by
+ ).
@@ -4239,7 +4108,46 @@ Hello
+
+
+Using Template Haskell with Profiling
+profilingwith Template Haskell
+Template Haskell relies on GHC's built-in bytecode compiler and
+interpreter to run the splice expressions. The bytecode interpreter
+runs the compiled expression on top of the same runtime on which GHC
+itself is running; this means that the compiled code referred to by
+the interpreted expression must be compatible with this runtime, and
+in particular this means that object code that is compiled for
+profiling cannot be loaded and used by a splice
+expression, because profiled object code is only compatible with the
+profiling version of the runtime.
+
+This causes difficulties if you have a multi-module program
+containing Template Haskell code and you need to compile it for
+profiling, because GHC cannot load the profiled object code and use it
+when executing the splices. Fortunately GHC provides a workaround.
+The basic idea is to compile the program twice:
+
+
+
+ Compile the program or library first the normal way, without
+ .
+
+
+ Then compile it again with , and
+ additionally use
+ to name the object files differentliy (you can choose any suffix
+ that isn't the normal object suffix here). GHC will automatically
+ load the object files built in the first step when executing splice
+ expressions. If you omit the flag when
+ building with and Template Haskell is used,
+ GHC will emit an error message.
+
+
+
+
@@ -4734,6 +4642,150 @@ Because the preprocessor targets Haskell (rather than Core),
+
+
+
+Bang patterns
+Bang patterns
+
+GHC supports an extension of pattern matching called bang
+patterns. Bang patterns are under consideration for Haskell Prime.
+The Haskell
+prime feature description contains more discussion and examples
+than the material below.
+
+
+Bang patterns are enabled by the flag .
+
+
+
+Informal description of bang patterns
+
+
+The main idea is to add a single new production to the syntax of patterns:
+
+ pat ::= !pat
+
+Matching an expression e against a pattern !p is done by first
+evaluating e (to WHNF) and then matching the result against p.
+Example:
+
+f1 !x = True
+
+This definition makes f1 is strict in x,
+whereas without the bang it would be lazy.
+Bang patterns can be nested of course:
+
+f2 (!x, y) = [x,y]
+
+Here, f2 is strict in x but not in
+y.
+A bang only really has an effect if it precedes a variable or wild-card pattern:
+
+f3 !(x,y) = [x,y]
+f4 (x,y) = [x,y]
+
+Here, f3 and f4 are identical; putting a bang before a pattern that
+forces evaluation anyway does nothing.
+
+Bang patterns work in case expressions too, of course:
+
+g5 x = let y = f x in body
+g6 x = case f x of { y -> body }
+g7 x = case f x of { !y -> body }
+
+The functions g5 and g6 mean exactly the same thing.
+But g7 evalutes (f x), binds y to the
+result, and then evaluates body.
+
+Bang patterns work in let and where
+definitions too. For example:
+
+let ![x,y] = e in b
+
+is a strict pattern: operationally, it evaluates e, matches
+it against the pattern [x,y], and then evaluates b
+The "!" should not be regarded as part of the pattern; after all,
+in a function argument ![x,y] means the
+same as [x,y]. Rather, the "!"
+is part of the syntax of let bindings.
+
+
+
+
+
+Syntax and semantics
+
+
+
+We add a single new production to the syntax of patterns:
+
+ pat ::= !pat
+
+There is one problem with syntactic ambiguity. Consider:
+
+f !x = 3
+
+Is this a definition of the infix function "(!)",
+or of the "f" with a bang pattern? GHC resolves this
+ambiguity inf favour of the latter. If you want to define
+(!) with bang-patterns enabled, you have to do so using
+prefix notation:
+
+(!) f x = 3
+
+The semantics of Haskell pattern matching is described in
+Section 3.17.2 of the Haskell Report. To this description add
+one extra item 10, saying:
+Matching
+the pattern !pat against a value v behaves as follows:
+if v is bottom, the match diverges
+ otherwise, pat is matched against
+ v
+
+
+Similarly, in Figure 4 of
+Section 3.17.3, add a new case (t):
+
+case v of { !pat -> e; _ -> e' }
+ = v `seq` case v of { pat -> e; _ -> e' }
+
+
+That leaves let expressions, whose translation is given in
+Section
+3.12
+of the Haskell Report.
+In the translation box, first apply
+the following transformation: for each pattern pi that is of
+form !qi = ei, transform it to (xi,!qi) = ((),ei), and and replace e0
+by (xi `seq` e0). Then, when none of the left-hand-side patterns
+have a bang at the top, apply the rules in the existing box.
+
+The effect of the let rule is to force complete matching of the pattern
+qi before evaluation of the body is begun. The bang is
+retained in the translated form in case qi is a variable,
+thus:
+
+ let !y = f x in b
+
+
+
+
+The let-binding can be recursive. However, it is much more common for
+the let-binding to be non-recursive, in which case the following law holds:
+(let !p = rhs in body)
+ is equivalent to
+(case rhs of !p -> body)
+
+
+A pattern with a bang at the outermost level is not allowed at the top level of
+a module.
+
+
+
+
@@ -5013,63 +5065,58 @@ key_function :: Int -> String -> (Bool, Double)
If you use you'll see the
sequence of phase numbers for successive runs of the
simplifier. In an INLINE pragma you can optionally specify a
- phase number, thus:
-
+ phase number, thus:
- You can say "inline f in Phase 2
- and all subsequent phases":
-
- {-# INLINE [2] f #-}
-
-
-
-
+ "INLINE[k] f" means: do not inline
+ f
+ until phase k, but from phase
+ k onwards be very keen to inline it.
+
- You can say "inline g in all
- phases up to, but not including, Phase 3":
-
- {-# INLINE [~3] g #-}
-
-
-
-
+ "INLINE[~k] f" means: be very keen to inline
+ f
+ until phase k, but from phase
+ k onwards do not inline it.
+
- If you omit the phase indicator, you mean "inline in
- all phases".
-
+ "NOINLINE[k] f" means: do not inline
+ f
+ until phase k, but from phase
+ k onwards be willing to inline it (as if
+ there was no pragma).
+
+
+ "INLINE[~k] f" means: be willing to inline
+ f
+ until phase k, but from phase
+ k onwards do not inline it.
+
-
- You can use a phase number on a NOINLINE pragma too:
-
-
-
- You can say "do not inline f
- until Phase 2; in Phase 2 and subsequently behave as if
- there was no pragma at all":
+The same information is summarised here:
- {-# NOINLINE [2] f #-}
-
-
-
+ -- Before phase 2 Phase 2 and later
+ {-# INLINE [2] f #-} -- No Yes
+ {-# INLINE [~2] f #-} -- Yes No
+ {-# NOINLINE [2] f #-} -- No Maybe
+ {-# NOINLINE [~2] f #-} -- Maybe No
-
- You can say "do not inline g in
- Phase 3 or any subsequent phase; before that, behave as if
- there was no pragma":
-
- {-# NOINLINE [~3] g #-}
+ {-# INLINE f #-} -- Yes Yes
+ {-# NOINLINE f #-} -- No No
-
-
-
-
- If you omit the phase indicator, you mean "never
- inline this function".
-
-
-
- The same phase-numbering control is available for RULES
+By "Maybe" we mean that the usual heuristic inlining rules apply (if the
+function body is small, or it is applied to interesting-looking arguments etc).
+Another way to understand the semantics is this:
+
+For both INLINE and NOINLINE, the phase number says
+when inlining is allowed at all.
+The INLINE pragma has the additional effect of making the
+function body look small, so that when inlining is allowed it is very likely to
+happen.
+
+
+
+The same phase-numbering control is available for RULES
().
@@ -5347,7 +5394,9 @@ The programmer can specify rewrite rules as part of the source program
(in a pragma). GHC applies these rewrite rules wherever it can, provided (a)
the flag () is on,
and (b) the flag
-() is not specified.
+() is not specified, and (c) the
+ ()
+flag is active.
@@ -5669,7 +5718,7 @@ The following are good producers:
- filter
+take, filter
@@ -5732,7 +5781,7 @@ The following are good consumers:
- filter
+take, filter
@@ -5997,6 +6046,89 @@ r) ->
+
+Special built-in functions
+GHC has a few built-in funcions with special behaviour,
+described in this section. All are exported by
+GHC.Exts.
+
+The inline function
+
+The inline function is somewhat experimental.
+
+ inline :: a -> a
+
+The call (inline f) arranges that f
+is inlined, regardless of its size. More precisely, the call
+(inline f) rewrites to the right-hand side of f's
+definition.
+This allows the programmer to control inlining from
+a particular call site
+rather than the definition site of the function
+(c.f. INLINE pragmas ).
+
+
+This inlining occurs regardless of the argument to the call
+or the size of f's definition; it is unconditional.
+The main caveat is that f's definition must be
+visible to the compiler. That is, f must be
+let-bound in the current scope.
+If no inlining takes place, the inline function
+expands to the identity function in Phase zero; so its use imposes
+no overhead.
+
+ If the function is defined in another
+module, GHC only exposes its inlining in the interface file if the
+function is sufficiently small that it might be
+inlined by the automatic mechanism. There is currently no way to tell
+GHC to expose arbitrarily-large functions in the interface file. (This
+shortcoming is something that could be fixed, with some kind of pragma.)
+
+
+
+The lazy function
+
+The lazy function restrains strictness analysis a little:
+
+ lazy :: a -> a
+
+The call (lazy e) means the same as e,
+but lazy has a magical property so far as strictness
+analysis is concerned: it is lazy in its first argument,
+even though its semantics is strict. After strictness analysis has run,
+calls to lazy are inlined to be the identity function.
+
+
+This behaviour is occasionally useful when controlling evaluation order.
+Notably, lazy is used in the library definition of
+Control.Parallel.par:
+
+ par :: a -> b -> b
+ par x y = case (par# x) of { _ -> lazy y }
+
+If lazy were not lazy, par would
+look strict in y which would defeat the whole
+purpose of par.
+
+
+
+The unsafeCoerce# function
+
+The function unsafeCoerce# allows you to side-step the
+typechecker entirely. It has type
+
+ unsafeCoerce# :: a -> b
+
+That is, it allows you to coerce any type into any other type. If you use this
+function, you had better get it right, otherwise segmentation faults await.
+It is generally used when you want to write a program that you know is
+well-typed, but where Haskell's type system is not expressive enough to prove
+that it is well typed.
+
+
+
+
+
Generic classes
@@ -6253,6 +6385,51 @@ Just to finish with, here's another example I rather like:
+
+Control over monomorphism
+
+GHC supports two flags that control the way in which generalisation is
+carried out at let and where bindings.
+
+
+
+Switching off the dreaded Monomorphism Restriction
+
+
+Haskell's monomorphism restriction (see
+Section
+4.5.5
+of the Haskell Report)
+can be completely switched off by
+.
+
+
+
+
+Monomorphic pattern bindings
+
+
+
+ As an experimental change, we are exploring the possibility of
+ making pattern bindings monomorphic; that is, not generalised at all.
+ A pattern binding is a binding whose LHS has no function arguments,
+ and is not a simple variable. For example:
+
+ f x = x -- Not a pattern binding
+ f = \x -> x -- Not a pattern binding
+ f :: Int -> Int = \x -> x -- Not a pattern binding
+
+ (g,h) = e -- A pattern binding
+ (f) = e -- A pattern binding
+ [x] = e -- A pattern binding
+
+Experimentally, GHC now makes pattern bindings monomorphic by
+default. Use to recover the
+standard behaviour.
+
+
+
+