OK i’ve fixed these. will push when I have valiated
From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com]
Sent: 14 January 2013 18:40
To: Simon Peyton-Jones
Cc: ghc-devs@haskell.org
Subject: Re: Failing test
Hello,
On Mon, Jan 14, 2013 at 9:52 AM, Simon Peyton-Jones mailto:simonpj@microsoft.com> wrote:
Are these four failures the result of your changes?
Should we fix the tests?
(sorry, this went to the fun-dep thread so it probably got buried among the other e-mails).
About the tests: When I ran the type-checker tests, I got these 3 failures that I am not sure how to fix:
Unexpected failures:
should_compile tc226 [exit code non-0] (hpc,optasm)
should_compile tc235 [exit code non-0] (normal,hpc,optasm)
should_fail T5684 [stderr mismatch] (normal)
- tc226 appears to be completely unrelated to my changes, so I imagine it is about something else?
- tc235 is a program that is now rejected. I am not sure how to fix this test as the program inside seems incorrect at many levels (e.g., it violates the FD of the class, but it also uses ambiguous methods). I also couldn't figure out what it is testing.
- T5684 is still rejected but with a different error, because one of the instances violates the FD of the class. However, this test appears to be carefully designed to test something else, but I didn't quite follow exactly what, so I left it as is for the moment.
Would you mind taking a look and advising on what to do? I think that the new behavior is correct for tc235 and T5684, but it would be nice to preserve whatever was originally tasted there (unless it was an artifact of the lax checking of the FDs)
Should the error message say “The instance decl is inconsistent with the fundeps”? And maybe be more precise about which fundep.
We could do that. The current message replaces "the Coverage Condition fails for one of the functional dependencies", because I thought that it is more descriptive. The way the tests is written---both the coverage condition, and the new one---they return just a boolean, but I could probably to return the FD that is being violated. I'll have a go at it.
I’m a bit confused.
About which part? Here is an example of what we are checking for:
class C a b | a -> b
instance C Int b -- bad instance
The instance violated the FD on the class because it implies that both `C Int Int` and `C Int Char` hold, which violated the FD. This is what I meant by "multiple uses of the instance may violate the functional dependency". The reason I opted to go for "may" in the message is because strictly speaking the test is incomplete (i.e., there are somewhat contrived examples that are consistent with the FD, but would be rejected, I can send one if it'd be useful?).
-Iavor
