Concerning (1) yes, this is a recent and substantial improvement in GHC (HEAD only).
Concerning (3), this is a plain bug. I've just fixed it in the HEAD. I very much doubt I'll fix it in 6.6, because type inference in the HEAD now works rather differently.
Thanks for the example; I've added it to the test suite!
Simon
| -----Original Message-----
| From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jim
| Apple
| Sent: 09 January 2007 01:52
| To: haskell-cafe@haskell.org
| Subject: Re: [Haskell-cafe] Monad Set via GADT
|
| On 1/3/07, Roberto Zunino wrote:
| > 1) Why the first version did not typececk?
| > 2) Why the second one does?
| > 3) If I replace (Teq a w) with (Teq w a), as in
| > SM :: Ord w => Teq w a -> Set.Set w -> SetM a
| > then union above does not typecheck! Why? I guess the type variable
| > unification deriving from matching Teq is not symmetric as I expect it
| > to be...
|
| These are very interesting questions that I forgot about until
| reminded by Haskell Weekly News. Thanks, HWN!
|
| 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...
|
| 2) The second one works because Class constraints can be used when
| pattern matching existentials.
|
| 3) I imagine this might have something to do with the coercions that
| System FC uses. With one ordering, a coercion might occur that in
| another one is unnecessary. This coercion might allow the use of Ord w
| by using it before the coercion from S.Set a to S.Set w.
|
| #3 is just a guess.
|
| Jim
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe
