|Version 7 (modified by igloo, 6 years ago) (diff)|
|GHC||full in HEAD (-XNoDatatypeContexts)|
H98 and H2010 allow a context to be given for datatypes, e.g. the Eq a in
data Eq a => Foo a = Constr a
This proposal is to remove support for that context.
Datatype contexts (called "stupid theta" in GHC sources) appear, at first glance, to be very useful, but in actual fact they are not as useful as they seem.
One might expect that, with the above Foo type, one could write
isEq :: Foo a -> Foo a -> Bool isEq (Constr x) (Constr y) = x == y
and the compiler would know that there is an Eq a instance from the datatype context. However, this is not the case. We instead must write
isEq :: Eq a => Foo a -> Foo a -> Bool isEq (Constr x) (Constr y) = x == y
In fact, we cannot even write
getVal :: Foo a -> a getVal (Constr x) = x
We must write
getVal :: Eq a => Foo a -> a getVal (Constr x) = x
When we would expect the compiler to have the instance already available, in actual fact we have to provide it ourselves. The problem is that the constraint is not actually on the datatype, but rather, on the type of the constructor. Worse, the dictionary is not stored in the constructor, but simply discarded.
Effect of removing datatype contexts
It is possible to write programs whose behaviour changes when datatype contexts are removed, e.g. with:
data Floating a => Foo a = Constr a getIncVal (Constr x) = x + 1 foo = show (getIncVal (Constr 1))
foo is "2.0", while with
data Foo a = Constr a getIncVal (Constr x) = x + 1 foo = show (getIncVal (Constr 1))
foo is "2". Likewise it is possible that a program will fail to compile when datatype contexts are removed. However, in practice removing datatype contexts is unlikely to affect the behaviour of any real programs.
What removing the datatype contexts from a source file will do is make some previously illegal programs legal. However, we do not believe that the power that the datatype contexts feature provides is worth the burden the language construct places on implementors, documentors and educators. Other extensions being worked on, such as GADTs, have a much higher power to weight ratio.
There are 4 modules in base 4.3 that use datatype contexts:
In most cases, the type is specified in the H98 and H2010 report.
Doing a Hackage regression test with GHC 6.13.20100710, of the 2219 packages on Hackage, cabal-install is able to make an installation plan for 920, and GHC is actually able to compile 590. Of those 590, these 15 then fail if datatype contexts are turned off:
Making these packages buildable is assumed to be as simple as removing the datatype contexts, but this has not been verified.
The proposal was discussed in http://www.haskell.org/pipermail/haskell-prime/2010-July/003249.html
In the thread, it was pointed out that DrIFT uses the context as a hint for how to derive instances. However, other GP techniques and tools, which do not need the context, can be used instead.
It was also pointed out that they can be used as a hack to give the kind of an unused type variable, but there are other hacks that can be used instead (or the KindSignatures extension).
It was also pointed out that we could make the contexts do something useful instead, but there is no proposal for that, and it would probably overlap with other extensions such as existential types and GADTs.
Changes relative to H2010 report.
In Section 4:
In Section 4.2.1:
In Section 4.2.3:
In Section 10.5: