RE: [Haskell] Fundep broken in GHC 6.6
[redirecting to ghc users] Actually this didn't work in 6.4.2 either! (Though it did in 6.4, for reasons I have not investigated.) Indeed I think your reasoning is correct. GHC tries to be pretty relaxed about reporting ambiguous types, which is what this amounts to really. I have committed a fix to the HEAD that relaxes the condition, and allows this program. It should appear in 6.6.1 also. Thanks for the report Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] | On Behalf Of dpus | Sent: 12 November 2006 19:36 | To: haskell@haskell.org | Subject: [Haskell] Fundep broken in GHC 6.6 | | Hi, | | The following class declaration worked in GHC 6.4. | I recently upgraded to 6.6 (following Debian), and | now it is broken. | | class Error e => Game b mv e | b -> mv e where | newBoard :: MonadState b m => m () | ... | | Since MonadState has the fundep m -> b, the type | of newBoard fully specifies all of the class parameters. | And this worked fine in GHC 6.4. But GHC 6.6 | complains: | | The class method `newBoard' | mentions none of the type variables of the class Game b mv e | When checking the class method: newBoard :: m () | In the class declaration for `Game' | | Any ideas? | | Thanks, | Yitz | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell
On 12 November 2006 I wrote (on the haskell list):
class Error e => Game b mv e | b -> mv e where newBoard :: MonadState b m => m () ... Since MonadState has the fundep m -> b, the type of newBoard fully specifies all of the class parameters.... But GHC 6.6 complains...
Simon Peyton-Jones wrote:
I have committed a fix to the HEAD that relaxes the condition, and allows this program. It should appear in 6.6.1 also.
Thank you! Am I correct to assume that this fix only applies to the specific case of unspecified class parameters in method declarations? And not any of the other cases where fundeps on class constraints resolve type ambiguity but are ignored by GHC, such as instance declarations? Does the fix actually look at the fundeps in the class constraint on the method, or just relax the requirement that all class parameters be specified in every method? If it is the latter, as I suspect, then is the requirement always relaxed, or only when there is a class constraint on the method? Thanks, Yitz
I just applied this rule http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html... In this case the type of newBoard is newBoard :: (Game b mv e, MonadStaet b m) => m () Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn Simon | -----Original Message----- | From: sefer.org@gmail.com [mailto:sefer.org@gmail.com] On Behalf Of Yitzchak Gale | Sent: 03 January 2007 22:26 | To: Simon Peyton-Jones | Cc: GHC users | Subject: Re: [Haskell] Fundep broken in GHC 6.6 | | On 12 November 2006 I wrote (on the haskell list): | >> class Error e => Game b mv e | b -> mv e where | >> newBoard :: MonadState b m => m () | >> ... | >> Since MonadState has the fundep m -> b, the type | >> of newBoard fully specifies all of the class parameters.... | >> But GHC 6.6 complains... | | Simon Peyton-Jones wrote: | > I have committed a fix to the HEAD that relaxes the | > condition, and allows this program. | > It should appear in 6.6.1 also. | | Thank you! | | Am I correct to assume that this fix only applies to the | specific case of unspecified class parameters in | method declarations? And not any of the other cases | where fundeps on class constraints resolve type ambiguity | but are ignored by GHC, such as instance declarations? | | Does the fix actually look at the fundeps in the class | constraint on the method, or just relax the | requirement that all class parameters be specified in | every method? If it is the latter, as I suspect, then is | the requirement always relaxed, or only when there is | a class constraint on the method? | | Thanks, | Yitz
Simon Peyton-Jones wrote:
I just applied this rule http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html...
In this case the type of newBoard is newBoard :: (Game b mv e, MonadStaet b m) => m ()
Following the rules in that manual section, this type sig is (now) ok. Does that answer your qn
Yes, I think it does. I guess I'll only really know when I can either get my hands on 6.6.1, or successfully compile GHC from darcs. Thanks! -Yitz
participants (2)
-
Simon Peyton-Jones -
Yitzchak Gale