[Haskell-cafe] Monad Set via GADT
simonpj at microsoft.com
Tue Jan 9 08:55:39 EST 2007
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!
| -----Original Message-----
| From: haskell-cafe-bounces at haskell.org [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Jim
| Sent: 09 January 2007 01:52
| To: haskell-cafe at haskell.org
| Subject: Re: [Haskell-cafe] Monad Set via GADT
| On 1/3/07, Roberto Zunino <zunino at di.unipi.it> 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:
| 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.
| Haskell-Cafe mailing list
| Haskell-Cafe at haskell.org
More information about the Haskell-Cafe