X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;ds=sidebyside;f=docs%2Fusers_guide%2Fglasgow_exts.xml;h=14848159a438479d5bb4a7f3c586c7faeed165db;hb=1bb3a4f7ea0b4005adb5d1a582a3796d152bc33e;hp=5a4c46584a729c96406e4eda390f111fc4bb2f97;hpb=9d1247b3dad4fe152503dafa995fa06428e1a04b;p=ghc-hetmet.git
diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index 5a4c465..1484815 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -1410,7 +1410,7 @@ records from different modules that use the same field name.
-Record puns are enabled by the flag -XRecordPuns.
+Record puns are enabled by the flag -XNamedFieldPuns.
@@ -1568,6 +1568,29 @@ necessary to enable them.
+
+ Package-qualified imports
+
+ With the flag, GHC allows
+ import declarations to be qualified by the package name that the
+ module is intended to be imported from. For example:
+
+
+import "network" Network.Socket
+
+
+ would import the module Network.Socket from
+ the package network (any version). This may
+ be used to disambiguate an import when the same module is
+ available from multiple packages, or is present in both the
+ current package being built and an external package.
+
+ Note: you probably don't need to use this feature, it was
+ added mainly so that we can build backwards-compatible versions of
+ packages when APIs change. It can lead to fragile dependencies in
+ the common case: modules occasionally move from one package to
+ another, rendering any package-qualified imports broken.
+
@@ -2436,11 +2459,17 @@ The result type of each constructor must begin with the type constructor being d
but for a GADT the arguments to the type constructor can be arbitrary monotypes.
For example, in the Term data
type above, the type of each constructor must end with Term ty, but
-the ty may not be a type variable (e.g. the Lit
+the ty need not be a type variable (e.g. the Lit
constructor).
+It's is permitted to declare an ordinary algebraic data type using GADT-style syntax.
+What makes a GADT into a GADT is not the syntax, but rather the presence of data constructors
+whose result type is not just T a b.
+
+
+
You cannot use a deriving clause for a GADT; only for
an ordinary data type.
@@ -2476,6 +2505,19 @@ their selector functions actually have different types:
+
+When pattern-matching against data constructors drawn from a GADT,
+for example in a case expression, the following rules apply:
+
+The type of the scrutinee must be rigid.
+The type of the result of the case expression must be rigid.
+The type of any free variable mentioned in any of
+the case alternatives must be rigid.
+
+A type is "rigid" if it is completely known to the compiler at its binding site. The easiest
+way to ensure that a variable a rigid type is to give it a type signature.
+
+
@@ -2533,9 +2575,27 @@ The syntax is identical to that of an ordinary instance declaration apart from (
You must supply a context (in the example the context is (Eq a)),
exactly as you would in an ordinary instance declaration.
(In contrast the context is inferred in a deriving clause
-attached to a data type declaration.) These deriving instance
-rules obey the same rules concerning form and termination as ordinary instance declarations,
-controlled by the same flags; see .
+attached to a data type declaration.)
+
+A deriving instance declaration
+must obey the same rules concerning form and termination as ordinary instance declarations,
+controlled by the same flags; see .
+
+
+Unlike a deriving
+declaration attached to a data declaration, the instance can be more specific
+than the data type (assuming you also use
+-XFlexibleInstances, ). Consider
+for example
+
+ data Foo a = Bar a | Baz String
+
+ deriving instance Eq a => Eq (Foo [a])
+ deriving instance Eq a => Eq (Foo (Maybe a))
+
+This will generate a derived instance for (Foo [a]) and (Foo (Maybe a)),
+but other types such as (Foo (Int,Bool)) will not be an instance of Eq.
+The stand-alone syntax is generalised for newtypes in exactly the same
way that ordinary deriving clauses are generalised ().
@@ -3251,7 +3311,7 @@ corresponding type in the instance declaration.
These restrictions ensure that context reduction terminates: each reduction
step makes the problem smaller by at least one
constructor. Both the Paterson Conditions and the Coverage Condition are lifted
-if you give the
+if you give the
flag ().
You can find lots of background material about the reason for these
restrictions in the paper
-
- DEPRECATED pragma
- DEPRECATED
-
+
+ WARNING and DEPRECATED pragmas
+ WARNING
+ DEPRECATED
- The DEPRECATED pragma lets you specify that a particular
- function, class, or type, is deprecated. There are two
- forms.
+ The WARNING pragma allows you to attach an arbitrary warning
+ to a particular function, class, or type.
+ A DEPRECATED pragma lets you specify that
+ a particular function, class, or type is deprecated.
+ There are two ways of using these pragmas.
- You can deprecate an entire module thus:
+ You can work on an entire module thus:
module Wibble {-# DEPRECATED "Use Wobble instead" #-} where
...
+ Or:
+
+ module Wibble {-# WARNING "This is an unstable interface." #-} where
+ ...
+When you compile any module that import
Wibble, GHC will print the specified
message.
- You can deprecate a function, class, type, or data constructor, with the
- following top-level declaration:
+ You can attach a warning to a function, class, type, or data constructor, with the
+ following top-level declarations:
{-# DEPRECATED f, C, T "Don't use these" #-}
+ {-# WARNING unsafePerformIO "This is unsafe; I hope you know what you're doing" #-}
When you compile any module that imports and uses any
of the specified entities, GHC will print the specified
message.
- You can only deprecate entities declared at top level in the module
+ You can only attach to entities declared at top level in the module
being compiled, and you can only use unqualified names in the list of
- entities being deprecated. A capitalised name, such as T
+ entities. A capitalised name, such as T
refers to either the type constructor Tor the data constructor T, or both if
- both are in scope. If both are in scope, there is currently no way to deprecate
- one without the other (c.f. fixities ).
+ both are in scope. If both are in scope, there is currently no way to
+ specify one without the other (c.f. fixities
+ ).
- Any use of the deprecated item, or of anything from a deprecated
- module, will be flagged with an appropriate message. However,
- deprecations are not reported for
- (a) uses of a deprecated function within its defining module, and
- (b) uses of a deprecated function in an export list.
+ Warnings and deprecations are not reported for
+ (a) uses within the defining module, and
+ (b) uses in an export list.
The latter reduces spurious complaints within a library
in which one module gathers together and re-exports
the exports of several others.
You can suppress the warnings with the flag
- .
+ .