X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=ghc%2Fdocs%2Fusers_guide%2Fglasgow_exts.sgml;h=5c809257b901db00a3b87676ca0789d79bea12c7;hb=277cd58374ee122c3ae4dc7d99a10971facaf830;hp=951b59c19cef20755f5f776194e5a61853f98e6b;hpb=2d4a00233762ff9b5944e4bd0451d9dc6fe974a5;p=ghc-hetmet.git
diff --git a/ghc/docs/users_guide/glasgow_exts.sgml b/ghc/docs/users_guide/glasgow_exts.sgml
index 951b59c..5c80925 100644
--- a/ghc/docs/users_guide/glasgow_exts.sgml
+++ b/ghc/docs/users_guide/glasgow_exts.sgml
@@ -96,6 +96,22 @@ Executive summary of our extensions:
+ Data types with no constructors
+
+ See .
+
+
+
+
+ Parallel list comprehensions
+
+ An extension to the list comprehension syntax to support
+ zipWith-like functionality. See .
+
+
+
+ Foreign calling:Just what it sounds like. We provide
@@ -126,6 +142,9 @@ Executive summary of our extensions:
Generic classes:
+ (Note: support for generic classes is currently broken
+ in GHC 5.02).
+
Generic class declarations allow you to define a class
whose methods say how to work over an arbitrary data type.
Then it's really easy to make any new type into an instance of
@@ -275,8 +294,9 @@ program), you may wish to check if there are libraries that provide a
slightly-non-standard reading is that there is no difficulty with
the literal -2147483648 at type Int;
it means fromInteger (-2147483648). The strict interpretation
- would be negate (fromInteger 21474836483),
- and the call to fromInteger would overflow (at type Int, remember).
+ would be negate (fromInteger 2147483648),
+ and the call to fromInteger would overflow
+ (at type Int, remember).
@@ -405,6 +425,24 @@ The libraries documentatation gives more details on all these
+
+Data types with no constructors
+
+With the flag, GHC lets you declare
+a data type with no constructors. For example:
+
+ data S -- S :: *
+ data T a -- T :: * -> *
+
+Syntactically, the declaration lacks the "= constrs" part. The
+type can be parameterised, but only over ordinary types, of kind *; since
+Haskell does not have kind signatures, you cannot parameterise over higher-kinded
+types.
+
+Such data types have only one value, namely bottom.
+Nevertheless, they can be useful when defining "phantom types".
+
+
Pattern guards
@@ -532,107 +570,55 @@ qualifier list has just one element, a boolean expression.
-
- The foreign interface
-
- The foreign interface consists of the following components:
-
-
-
- The Foreign Function Interface language specification
- (included in this manual, in ).
-
-
-
- The Foreign module (see ) collects together several interfaces
- which are useful in specifying foreign language
- interfaces, including the following:
-
-
-
- The ForeignObj module (see ), for managing pointers from
- Haskell into the outside world.
-
-
-
- The StablePtr module (see ), for managing pointers
- into Haskell from the outside world.
-
-
-
- The CTypes module (see ) gives Haskell equivalents for the
- standard C datatypes, for use in making Haskell bindings
- to existing C libraries.
-
-
-
- The CTypesISO module (see ) gives Haskell equivalents for C
- types defined by the ISO C standard.
-
-
-
- The Storable library, for
- primitive marshalling of data types between Haskell and
- the foreign language.
-
-
-
-
-
+
+ Parallel List Comprehensions
+ list comprehensionsparallel
+
+ parallel list comprehensions
+
-The following sections also give some hints and tips on the use
-of the foreign function interface in GHC.
+ Parallel list comprehensions are a natural extension to list
+ comprehensions. List comprehensions can be thought of as a nice
+ syntax for writing maps and filters. Parallel comprehensions
+ extend this to include the zipWith family.
-
-Using function headers
-
+ A parallel list comprehension has multiple independent
+ branches of qualifier lists, each separated by a `|' symbol. For
+ example, the following zips together two lists:
-
-C calls, function headers
-
+
+ [ (x, y) | x <- xs | y <- ys ]
+
-
-When generating C (using the directive), one can assist the
-C compiler in detecting type errors by using the -#include directive
-to provide .h files containing function headers.
-
+ The behavior of parallel list comprehensions follows that of
+ zip, in that the resulting list will have the same length as the
+ shortest branch.
-
-For example,
-
+ We can define parallel list comprehensions by translation to
+ regular comprehensions. Here's the basic idea:
-
+ Given a parallel comprehension of the form:
-#include "HsFFI.h"
-
-void initialiseEFS (HsInt size);
-HsInt terminateEFS (void);
-HsForeignObj emptyEFS(void);
-HsForeignObj updateEFS (HsForeignObj a, HsInt i, HsInt x);
-HsInt lookupEFS (HsForeignObj a, HsInt i);
+ [ e | p1 <- e11, p2 <- e12, ...
+ | q1 <- e21, q2 <- e22, ...
+ ...
+ ]
-
- The types HsInt,
- HsForeignObj etc. are described in .
+ This will be translated to:
- Note that this approach is only
- essential for returning
- floats (or if sizeof(int) !=
- sizeof(int *) on your architecture) but is a Good
- Thing for anyone who cares about writing solid code. You're
- crazy not to do it.
+
+ [ e | ((p1,p2), (q1,q2), ...) <- zipN [(p1,p2) | p1 <- e11, p2 <- e12, ...]
+ [(q1,q2) | q1 <- e21, q2 <- e22, ...]
+ ...
+ ]
+
-
+ where `zipN' is the appropriate zip for the given number of
+ branches.
-
+ Multi-parameter type classes
@@ -2097,6 +2083,8 @@ In particular, it is in scope at the type signature for <VarName>y</VarName>.
</para>
<para>
+ Pattern type signatures are completely orthogonal to ordinary, separate
+type signatures. The two can be used independently or together.
At ordinary type signatures, such as that for <VarName>ys</VarName>, any type variables
mentioned in the type signature <emphasis>that are not in scope</emphasis> are
implicitly universally quantified. (If there are no type variables in
@@ -2119,6 +2107,46 @@ So much for the basic idea. Here are the details.
</para>
<sect2>
+<title>What a pattern type signature means
+
+A type variable brought into scope by a pattern type signature is simply
+the name for a type. The restriction they express 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
@@ -2127,15 +2155,25 @@ So much for the basic idea. Here are the details.
- All the type variables mentioned in the patterns for a single
-function definition equation, that are not already in scope,
-are brought into scope by the patterns. We describe this set as
-the type variables bound by the equation.
-
+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 variables thus brought into scope may be mentioned
in ordinary type signatures or pattern type signatures anywhere within
@@ -2143,35 +2181,34 @@ 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.
-
+
There is no implicit universal quantification on pattern type
signatures, nor may one write an explicit forall type in a pattern
@@ -2179,8 +2216,8 @@ type signature. The pattern type signature is a monotype.
-
+
The type variables in the head of a class or instance declaration
@@ -2209,103 +2246,6 @@ scope over the methods defined in the where part. For exampl
-Polymorphism
-
-
-
-
-
-
-
- Pattern type signatures are completely orthogonal to ordinary, separate
-type signatures. The two can be used independently or together. There is
-no scoping associated with the names of the type variables in a separate type signature.
-
-
-
- f :: [a] -> [a]
- f (xs::[b]) = reverse xs
-
-
-
-
-
-
-
-
- The function must be polymorphic in the type variables
-bound by all its equations. Operationally, the type variables bound
-by one equation must not:
-
-
-
-
-
-
- Be unified with a type (such as Int, or [a]).
-
-
-
-
-
- Be unified with a type variable free in the environment.
-
-
-
-
-
- Be unified with each other. (They may unify with the type variables
-bound by another equation for the same function, of course.)
-
-
-
-
-
-
-For example, the following all fail to type check:
-
-
-
- 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]
-
-
-
-
-
-
-
-
- The pattern-bound type variable may, however, be constrained
-by the context of the principal type, thus:
-
-
-
- f (x::a) (y::a) = x+y*2
-
-
-
-gets the inferred type: forall a. Num a => a -> a -> a.
-
-
-
-
-
-
-
-
-
-Result type signatures
@@ -2349,16 +2289,17 @@ Result type signatures are not yet implemented in Hugs.
-Pattern signatures on other constructs
+Where a pattern type signature can occur
-
+A pattern type signature can occur in any pattern, but there
+are restrictions on pattern bindings:
-
+
- A pattern type signature can be on an arbitrary sub-pattern, not
-just on a variable:
+A pattern type signature can be on an arbitrary sub-pattern, not
+ust on a variable:
@@ -2374,28 +2315,9 @@ just on a variable:
Pattern type signatures, including the result part, can be used
in lambda abstractions:
-
(\ (x::a, y) :: a -> x)
-
-
-Type variables bound by these patterns must be polymorphic in
-the sense defined above.
-For example:
-
-
-
- f1 (x::c) = f1 x -- ok
- f2 = \(x::c) -> f2 x -- not ok
-
-
-
-Here, f1 is OK, but f2 is not, because c gets unified
-with a type variable free in the environment, in this
-case, the type of f2, which is in the environment when
-the lambda abstraction is checked.
-
@@ -2409,50 +2331,50 @@ in case expressions:
case e of { (x::a, y) :: a -> x }
+
+
-The pattern-bound type variables must, as usual,
-be polymorphic in the following sense: each case alternative,
-considered as a lambda abstraction, must be polymorphic.
-Thus this is OK:
-
-
-
- case (True,False) of { (x::a, y) -> x }
-
-
-
-Even though the context is that of a pair of booleans,
-the alternative itself is polymorphic. Of course, it is
-also OK to say:
+
+
+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:
- case (True,False) of { (x::Bool, y) -> x }
+ \ x :: a -> b -> x
+
-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:
+ Pattern type signatures can bind existential type variables.
+For example:
- \ x :: a -> b -> x
+ data T = forall a. MkT [a]
+
+ f :: T -> T
+ f (MkT [t::a]) = MkT t3
+ where
+ t3::[a] = [t,t,t]
+
+
- Pattern type signatures that bind new type variables
+Pattern type signatures that bind new type variables
may not be used in pattern bindings at all.
So this is illegal:
@@ -2506,49 +2428,31 @@ would get a monomorphic type.
-
-Existentials
-
-
-
-
-
-
-
- Pattern type signatures can bind existential type variables.
-For example:
-
-
-
- data T = forall a. MkT [a]
-
- f :: T -> T
- f (MkT [t::a]) = MkT t3
- where
- t3::[a] = [t,t,t]
-
+
-
-
+
+ Pragmas
-
+ pragma
-
+ GHC supports several pragmas, or instructions to the
+ compiler placed in the source code. Pragmas don't normally affect
+ the meaning of the program, but they might affect the efficiency
+ of the generated code.
-
+ Pragmas all take the form
-
+{-# word ... #-}
-
-Pragmas
-
-
-
-GHC supports several pragmas, or instructions to the compiler placed
-in the source code. Pragmas don't affect the meaning of the program,
-but they might affect the efficiency of the generated code.
-
+ where word indicates the type of
+ pragma, and is followed optionally by information specific to that
+ type of pragma. Case is ignored in
+ word. The various values for
+ word that GHC understands are described
+ in the following sections; any pragma encountered with an
+ unrecognised word is (silently)
+ ignored.INLINE pragma
@@ -2620,17 +2524,23 @@ For example, in GHC's own <literal>UniqueSupply</literal> monad code, we have:
<title>NOINLINE pragma
-NOINLINE pragma
-pragma, NOINLINE
-
+pragmaNOINLINE
+NOTINLINE pragma
+pragmaNOTINLINE
-The NOINLINE pragma does exactly what you'd expect: it stops the
-named function from being inlined by the compiler. You shouldn't ever
-need to do this, unless you're very cautious about code size.
+The NOINLINE pragma does exactly what you'd expect:
+it stops the named function from being inlined by the compiler. You
+shouldn't ever need to do this, unless you're very cautious about code
+size.
+NOTINLINE is a synonym for
+NOINLINE (NOTINLINE is specified
+by Haskell 98 as the standard way to disable inlining, so it should be
+used if you want your code to be portable).
+
@@ -2760,6 +2670,42 @@ The RULES pragma lets you specify rewrite rules. It is described in
+
+DEPRECATED pragma
+
+
+The DEPRECATED pragma lets you specify that a particular function, class, or type, is deprecated.
+There are two forms.
+
+
+
+You can deprecate an entire module thus:
+
+ module Wibble {-# DEPRECATED "Use Wobble instead" #-} where
+ ...
+
+
+When you compile any module that import Wibble, GHC will print
+the specified message.
+
+
+
+
+You can deprecate a function, class, or type, with the following top-level declaration:
+
+
+ {-# DEPRECATED f, C, T "Don't use these" #-}
+
+
+When you compile any module that imports and uses any of the specifed entities,
+GHC will print the specified message.
+
+
+
+You can suppress the warnings with the flag .
+
+
+
@@ -3065,14 +3011,14 @@ The following are good producers:
++
-
+map
-
+filter
@@ -3122,8 +3068,14 @@ The following are good consumers:
++ (on its first argument)
+
+
+ foldr
+
+
+map
@@ -3317,6 +3269,9 @@ program even if fusion doesn't happen. More rules in PrelList.lhs
Generic classes
+ (Note: support for generic classes is currently broken in
+ GHC 5.02).
+
The ideas behind this extension are described in detail in "Derivable type classes",
Ralf Hinze and Simon Peyton Jones, Haskell Workshop, Montreal Sept 2000, pp94-105.
@@ -3366,7 +3321,10 @@ where clause and over-ride whichever methods you please.
To use generics you need to
- Use the flag.
+ Use the flags (to enable the extra syntax),
+ (to generate extra per-data-type code),
+ and (to make the Generics library
+ available. Import the module Generics from the
@@ -3387,7 +3345,7 @@ can be written infix (indeed, you can now use
any operator starting in a colon as an infix type constructor). Also note that
the type constructors are not exactly as in the paper (Unit instead of 1, etc).
Finally, note that the syntax of the type patterns in the class declaration
-uses "{|" and "{|" brackets; curly braces
+uses "{|" and "|}" brackets; curly braces
alone would ambiguous when they appear on right hand sides (an extension we
anticipate wanting).
@@ -3469,10 +3427,10 @@ So this too is illegal:
class Foo a where
op1 :: a -> Bool
- op {| a :*: b |} (Inl x) = True
+ op1 {| a :*: b |} (x :*: y) = True
op2 :: a -> Bool
- op {| p :*: q |} (Inr y) = False
+ op2 {| p :*: q |} (x :*: y) = False
(The reason for this restriction is that we gather all the equations for a particular type consructor
into a single generic instance declaration.)