On Friday 12 January 2007 09:04, Simon Peyton-Jones wrote: > | > On 1/3/07, Roberto Zunino <[EMAIL PROTECTED]> 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/matc > |h=gadt+class+context > | > | 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.
Crystal clear. My remark was meant merely as a general observation. Cheers Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe