[Haskell-cafe] Re: Monad Set via GADT
benjamin.franksen at bessy.de
Fri Jan 12 05:57:11 EST 2007
On Friday 12 January 2007 09:04, Simon Peyton-Jones wrote:
> | > On 1/3/07, Roberto Zunino <zunino at di.unipi.it> 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
> | 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.
More information about the Haskell-Cafe