Revise the rules for -XExtendedDeafultRules

[simonpj]

The -XExtendedDefaultRules flag is very liberal about type-class defaults. Perhaps too liberal:

> *Main> quickCheck (\xs -> reverse xs == xs)
> +++ OK, passed 100 tests.

Not good (reverse on lists is not the identity function). I expect a type error! Reason: reverse on list of () is indeed the identity function!

The rules are currently these:

• All of the classes Ci are single-parameter type classes.
• At least one of the classes Ci is numeric, or is Show, Eq, or Ord.

Maybe we should tighten up the second rule to say:

• All of the classes Ci is numeric, or is Show, Eq, or Ord.

Then the Quickcheck example would not bogusly succeed in typechecking, because there's an Arbitrary constraint involved.

This ticket is to record the idea and canvas opinion. Record thoughts below.

See also

• #2853
• #2854

[igloo]

A couple of thoughts:

-Wall would warn about the defaulting. Perhaps in GHCi we could have a quieter warning on by default, so instead of either

<interactive>:1:35:
    Warning: Defaulting the following constraint(s) to type `()'
             `Eq a' arising from a use of `==' at <interactive>:1:35-50
             `Test.QuickCheck.Arbitrary a'
               arising from a use of `Test.QuickCheck.quickCheck'
                            at <interactive>:1:0-51
             `Show a'
               arising from a use of `Test.QuickCheck.quickCheck'
                            at <interactive>:1:0-51
    In the expression: reverse xs == xs
    In the first argument of `Test.QuickCheck.quickCheck', namely
        `(\ xs -> reverse xs == xs)'
    In a stmt of a 'do' expression:
        it <- Test.QuickCheck.quickCheck (\ xs -> reverse xs == xs)

or nothing we could get

Warning: Defaulting a type to ()

or

Warning: Defaulting a type to ()  (use -fwarn-whatever-it-is for more detail)

The other thought is getting very ad-hoc, but I think we only want defaulting to () in an IO a type.

[simonpj]

See also #2853 (only closed because it duplicates this one), which argues to make ExtendedDefaultRules more liberal, not less!

When finally fixing this, it'd be worth dealing with #1877 at the same time.

Simon

[guest]

There's no contradiction between #2853 and this bug report. In #2853 I argue that the defaulting rules should be more liberal about what the context can be when defaulting, but with the context still containing a Num. This report complains about a type being defaulted to ().

[simonpj]

Would you care to write a careful specification of your proposed new ExtendedDefaultRules rules?

Simon

[simonpj]

The new rules should also take account of #2854.