just a few comments from a user (who would really, really, like to be
able to define pragma collections, so that he doesn't have to switch
on half a dozen separate extensions every time;-).
The following toy program requires MultiParamTypeClasses OR
FlexibleContexts in order to be accepted by GHC(i):
f :: (T a b) => a -> Int
f _ = 0
This of course assumes that we import the definition of T, we *must*
have MultiParamTypeClasses enabled if we want to declare T. Both
extensions thus enable classes with more than one argument to appear
in contexts.
Only MultiParamTypeClasses does (and neither extension is needed in
the module defining 'f', if 'T' is imported, which suggests that
MultiParamTypeClasses is propagated to importers - this isn't true for
most other extensions). The documentation still points to -fglasgow-exts,
so it doesn't seem to answer these questions..
f :: (T a ()) => a -> Int
f _ = 0
i.e. changing the second argument to T to () instead, means we now
*must* have FlexibleInstances, in order to allow the non-tyvar
argument. This is nothing surprising, this is what FlexibleInstances
are supposed to do.
You mean FlexibleContexts.
But the question is, is this a syntactic issue or a typing issue?
FlexibleContexts has both syntax and static semantics implications.
Now, FlexibleInstances *also* lifts the restriction on contexts, just
like FlexibleContexts - but *only* for the contexts of instance
declarations.
No. FlexibleInstances is about instance *heads*, FlexibleContexts
is about contexts everywhere (in practice, there are some bugs;-).
class T a b -- requires MultiParamTypeClasses
instance T a a -- requires FlexibleInstances
instance Eq () => T a [b] -- requires FlexibleContexts
instance Eq [a] => T a b -- requires UndecidableInstances
(if you actually wanted to use 'T's methods, you'd then need
OverlappingInstances, but that, UndecidableInstances, and the
static semantics aspects of FlexibleContexts are beyond parsing)
I also seem to recall more dependencies between flags than I can
find documented.
Hth,
Claus
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
