X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fglasgow_exts.xml;h=aafe421c67cac1d260e837af53225d76e8c0259c;hb=7d7d29b6fd7967099856b6f7e0bf7ee2e7a212ea;hp=e19f5d0f28de6d3fa3f00a3faed5bf60782d8b75;hpb=dd82b49ad6f719bd324de7f2d63f3341c0e87694;p=ghc-hetmet.git
diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml
index e19f5d0..aafe421 100644
--- a/docs/users_guide/glasgow_exts.xml
+++ b/docs/users_guide/glasgow_exts.xml
@@ -87,7 +87,7 @@ documentation describes all the libraries that come with GHC.
,
.
Enabling these options is the only
- effect of -fglasgow-exts.
+ effect of .
We are trying to move away from this portmanteau flag,
and towards enabling features individually.
@@ -1176,8 +1176,9 @@ fromInteger :: Integer -> Bool -> Bool
Postfix operators
-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
+ The flag enables 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 !)
@@ -1194,10 +1195,6 @@ 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.
-Since this extension goes beyond Haskell 98, it should really be enabled
-by a flag; but in fact it is enabled all the time. (No Haskell 98 programs
-change their behaviour, of course.)
-The extension does not extend to the left-hand side of function
definitions; you must define such a function in prefix form.
@@ -1993,15 +1990,28 @@ main = do
display (inc (inc counterB)) -- prints "##"
-At the moment, record update syntax is only supported for Haskell 98 data types,
-so the following function does not work:
-
+Record update syntax is supported for existentials (and GADTs):
--- This is invalid; use explicit NewCounter instead for now
setTag :: Counter a -> a -> Counter a
setTag obj t = obj{ tag = t }
+The rule for record update is this:
+the types of the updated fields may
+mention only the universally-quantified type variables
+of the data constructor. For GADTs, the field may mention only types
+that appear as a simple type-variable argument in the constructor's result
+type. For example:
+
+data T a where { T1 { f1::a, f2::(a,b) } :: T a } -- b is existential
+upd1 t x = t { f1=x } -- OK: upd1 :: T a -> b -> T b
+upd2 t x = t { f2=x } -- BAD (f2's type mentions b, which is
+ -- existentially quantified)
+data G a b where { G1 { g1::a, g2::c } :: G a [c] }
+upd3 g x = g { g1=x } -- OK: upd3 :: G a b -> c -> G c b
+upd4 g x = g { g2=x } -- BAD (f2's type mentions c, which is not a simple
+ -- type-variable argument in G1's result type)
+
@@ -3250,9 +3260,6 @@ sets of instance declarations.
Instance declarations
-
-Relaxed rules for instance declarations
-
An instance declaration has the form
instance ( assertion1, ..., assertionn) => classtype1 ... typem where ...
@@ -3262,19 +3269,73 @@ The part before the "=>" is the
"=>" is the head of the instance declaration.
+
+Relaxed rules for the instance head
+
In Haskell 98 the head of an instance declaration
must be of the form C (T a1 ... an), where
-C is the class, T is a type constructor,
+C is the class, T is a data type constructor,
and the a1 ... an are distinct type variables.
-Furthermore, the assertions in the context of the instance declaration
+GHC relaxes these rules in two ways.
+
+
+
+The flag allows the head of the instance
+declaration to mention arbitrary nested types.
+For example, this becomes a legal instance declaration
+
+ instance C (Maybe Int) where ...
+
+See also the rules on overlap.
+
+
+With the flag, instance heads may use type
+synonyms. As always, using a type synonym is just shorthand for
+writing the RHS of the type synonym definition. For example:
+
+
+
+ type Point = (Int,Int)
+ instance C Point where ...
+ instance C [Point] where ...
+
+
+
+is legal. However, if you added
+
+
+
+ instance C (Int,Int) where ...
+
+
+
+as well, then the compiler will complain about the overlapping
+(actually, identical) instance declarations. As always, type synonyms
+must be fully applied. You cannot, for example, write:
+
+
+ type P a = [[a]]
+ instance Monad P where ...
+
+
+
+
+
+
+
+
+Relaxed rules for instance contexts
+
+In Haskell 98, the assertions in the context of the instance declaration
must be of the form C a where a
is a type variable that occurs in the head.
+
-The flag loosens these restrictions
-considerably. Firstly, multi-parameter type classes are permitted. Secondly,
-the context and head of the instance declaration can each consist of arbitrary
+The flag relaxes this rule, as well
+as the corresponding rule for type signatures (see ).
+With this flag the context of the instance declaration can each consist of arbitrary
(well-kinded) assertions (C t1 ... tn) subject only to the
following rules:
@@ -3572,47 +3633,6 @@ hard to pin down.) We are interested to receive feedback on these points.
-
-Type synonyms in the instance head
-
-
-Unlike Haskell 98, instance heads may use type
-synonyms. (The instance "head" is the bit after the "=>" in an instance decl.)
-As always, using a type synonym is just shorthand for
-writing the RHS of the type synonym definition. For example:
-
-
-
- type Point = (Int,Int)
- instance C Point where ...
- instance C [Point] where ...
-
-
-
-is legal. However, if you added
-
-
-
- instance C (Int,Int) where ...
-
-
-
-as well, then the compiler will complain about the overlapping
-(actually, identical) instance declarations. As always, type synonyms
-must be fully applied. You cannot, for example, write:
-
-
-
- type P a = [[a]]
- instance Monad P where ...
-
-
-
-This design decision is independent of all the others, and easily
-reversed, but it makes sense to me.
-
-
-
@@ -4331,6 +4351,31 @@ class (F a ~ b) => C a b where
+
+ Type families and instance declarations
+ Type families require us to extend the rules for
+ the form of instance heads, which are given
+ in .
+ Specifically:
+
+ Data type families may appear in an instance head
+ Type synonym families may not appear (at all) in an instance head
+
+The reason for the latter restriction is that there is no way to check for. Consider
+
+ type family F a
+ type instance F Bool = Int
+
+ class C a
+
+ instance C Int
+ instance C (F a)
+
+Now a constraint (C (F Bool)) would match both instances.
+The situation is especially bad because the type instance for F Bool
+might be in another module, or even in a module that is not yet written.
+
+