| > On 1/3/07, Roberto Zunino wrote:
| >> 1) Why the first version did not typececk?
| > 1) Class constraints can't be used on pattern matching. They ARE
| > restrictive on construction, however. This is arguably bug in the
| > Haskell standard. It is fixed in GHC HEAD for datatypes declared in
| > the GADT way, so as not to break H98 code:
| >
| http://article.gmane.org/gmane.comp.lang.haskell.cvs.all/29458/match=gadt+cl...
|
| To quote from there: "I think this is stupid, but it's what H98 says."
|
| Maybe it is time to consider it deprecated to follow the Haskell 98
| standard /to the letter/.
GHC follows this strange standard when you write data type decls in H98 form
data Eq a => T a = C a Int | D
Here, pattern-matching on either C or D will cause an (Eq a) constraint to be required.
However, GHC does *not* follow this convention when you write the data type decl in GADT style syntax:
data T a where
C :: Eq a => a -> Int -> T a
D :: T a
Here, (a) you can be selective; in this case, C has the context but D does not.
And (b) GHC treats the constraints sensibly:
- (Eq a) is *required* when C is used to construct a value
- (Eq a) is *provided* when C is used in pattern matching
In short, in GADT-style syntax, GHC is free to do as it pleases, so it does the "right" thing. In this case, then, you can avoid the H98 "bug" by using GADT-style syntax.
All of this is documented in the user manual. If it's not clear, please help me improve it.
Simon
