Failing test

[Iavor Diatchki]

Hello,


On Mon, Jan 14, 2013 at 9:52 AM, Simon Peyton-Jones
<simonpj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130114/6fde4e94/attachment.htm>