Opened 12 years ago

Closed 12 years ago

Last modified 9 years ago

#675 closed feature request (fixed)

Bad error message in GHCi

Reported by: guest Owned by:
Priority: normal Milestone:
Component: GHCi Version: 6.4.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:



import Test.QuickCheck

prop_eq_reflexive x = x == x

is loaded into GHCi the following can be observed:

*BadErrorMessage> quickCheck prop_eq_reflexive

Top level:
    No instance for (Show (IO ()))
      arising from use of `print' at Top level
    Probable fix: add an instance declaration for (Show (IO ()))
    In a 'do' expression: print it

Hugs gives the more understandable error message

BadErrorMessage> quickCheck prop_eq_reflexive
ERROR - Unresolved overloading
*** Type       : (Eq a, Show a, Arbitrary a) => IO ()
*** Expression : quickCheck prop_eq_reflexive

:t in GHCi gives an even more understandable error message:

*BadErrorMessage> :t quickCheck prop_eq_reflexive

    Ambiguous type variable `a' in the constraints:
      `Arbitrary a' arising from use of `quickCheck' at <interactive>:1:0-9
      `Eq a' arising from use of `prop_eq_reflexive' at <interactive>:1:11-27
      `Show a' arising from use of `quickCheck' at <interactive>:1:0-9
    Probable fix: add a type signature that fixes these type variable(s)

(In the introductory FP courses at Chalmers we use QuickCheck from the start, so this error message bites students in the first week.)

Change History (5)

comment:1 Changed 12 years ago by simonmar

Interestingly, GHC 6.5 doesn't report any error at all, presumably because it defaults the ambiguous type variable to ():

Prelude> :m +Debug.QuickCheck
Prelude Debug.QuickCheck> let prop_eq_reflexive x = x == x
Prelude Debug.QuickCheck> quickCheck prop_eq_reflexive
Loading package QuickCheck-1.0 ... linking ... done.
OK, passed 100 tests.
Prelude Debug.QuickCheck> :t quickCheck prop_eq_reflexive
quickCheck prop_eq_reflexive :: IO ()

Is this defaulting a little heavy handed, or is it the right thing?

comment:2 Changed 12 years ago by guest

In the context of Arbitrary it seems like a bad idea to silently default to (). You want the programmer to make an active choice here.

comment:3 Changed 12 years ago by simonpj

Resolution: fixed
Status: newclosed

Yes, I improved the error reporting in the head -- no more Show (IO ()) nonsense -- so I declare the original bug fixed.

As a separate matter, in the HEAD I also relaxed the defaulting rules, so that GHC will apply the standard defaulting rules if a) All of the ambiguous classes are single-parameter b) At least one is numeric, or Eq, Ord, or Show

In this case the conditions apply. GHC chooses Integer (not () as claimed) and runs the test at that type.

The relaxation of defaulting is easy to reverse if you don't like it, but people seemed to want it.

comment:4 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:5 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple
Note: See TracTickets for help on using tickets.