Opened 8 years ago

Closed 8 years ago

Last modified 6 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: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

If

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

<interactive>:1:0:
    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 8 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 8 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 8 years ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

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 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:5 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.