Revise the rules for -XExtendedDefaultRules

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 (closed)
• #2854 (closed)

changed weight to 5

added Tfeature request Trac import labels

changed milestone to %6.12 branch

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.

mentioned in issue #2853 (closed)

mentioned in issue #2854 (closed)

See also #2853 (closed) (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 (closed) at the same time.

Simon

There's no contradiction between #2853 (closed) and this bug report. In #2853 (closed) 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 ().

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

Simon

changed the description

The new rules should also take account of #2854 (closed).

changed title from Make -XExtendedDeafultRules a bit less liberal to Revise the rules for -XExtendedDeafultRules

changed milestone to %6.12.3

removed milestone

changed weight to 3

Trac metadata

Trac field	Value
Priority	normal → low

changed milestone to %7.0.2

changed milestone to %7.2.1

changed milestone to %7.4.1

changed milestone to %7.6.1

changed weight to 0

Trac metadata

Trac field	Value
Priority	low → lowest

changed milestone to %7.6.2

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure

mentioned in issue #8171

changed title from Revise the rules for -XExtendedDeafultRules to Revise the rules for -XExtendedDefaultRules

changed milestone to %7.10.1

Moving to 7.10.1.

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

changed milestone to %8.0.1

Milestone renamed

See also #8171, where it is proposed to make the rules //more// liberal.

Trac metadata

Trac field	Value
Related	- → #8171

added Plow label

mentioned in merge request !6876 (closed)