Constrained method type accepted in Haskell 98 mode

If I understand this paragraph of the GHC manual correctly, the following code should be rejected in Haskell 98 mode:

{-# LANGUAGE Haskell98 #-}

module Main where

class Compare a where
  comp :: Eq a => a -> a -> Bool

However, it compiles fine for me both with 7.4.2 and 7.6.1.

Trac metadata

Trac field	Value
Version	7.6.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Also accepted by 7.0.4 and 7.2.1, but rejected by 6.12.1. However, it complains about -XFlexibleContexts, not -XConstrainedClassMethods:

[1 of 1] Compiling Main             ( Test.hs, interpreted )

Test.hs:3:0:
    All of the type variables in the constraint `Eq a'
    are already in scope (at least one must be universally quantified here)
        (Use -XFlexibleContexts to lift this restriction)
    When checking the class method: comp :: (Eq a) => a -> a -> Bool
    In the class declaration for `Compare'
Failed, modules loaded: none.

Interestingly, the example from the manual seems to be always excepted if MultiParamTypeClasses are enabled:

  class Seq s a where
    fromList :: [a] -> s a
    elem     :: Eq a => a -> s a -> Bool

Replying to [ticket:7854#comment:70785 refold]:

seems to be always excepted

s/excepted/accepted/

You are absolutely right. See the H98 report http://www.haskell.org/onlinereport/decls.html. In 4.3.1. it says "the cxi may not constrain u", where u is the class variable, and cx is the context of a class method signature.

But (a) it's a bit fiddly to fix, (b) it's not clear what exactly it means for multi-parameter type classes, and more seriously it might break some existing programs which are inadvertently straying from H98 definition.

So I'm rather inclined to let sleeping dogs lie.

Simon

closed

1. .. it might break some existing programs which are inadvertently straying from H98 definition.

So I'm rather inclined to let sleeping dogs lie.

Closing as wontfix.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

reopened

Sorry for reopening, but I think the situation can be improved, currently -XConstrainedClassMethods seems to do nothing and the documentation is misleading. I would support deprecating and eventually removing this pragma, and adding a notice to "Known bugs and infelicities" section.

Trac metadata

Trac field	Value
Resolution	ResolvedWon'tFix → Unresolved

I agree with monoidal. Would someone like to do that?

Simon

added newcomer label

assigned to @trac-thomie

More bugs. GHC only rejects the following program when -XConstrainedClassMethods is turned on. It should however always reject it, because op doesn't mention any type variables of Foo.

module ShouldFail where
class Foo a where
  op :: Eq a => Int

I'm working on this.

Trac metadata

Trac field	Value
Component	Compiler → Compiler (Type checker)

added typechecker label

mentioned in issue #10118 (closed)

mentioned in issue #10119 (closed)

Patches are ready for review in D686, D687 and D688.

Instead of deprecating ConstrainedClassMethods, I have tried fixing it instead. D688 turns on ConstrainedClassMethods for all modes (Haskell98, Haskell2010 and default), to not break any programs. I added a section to "Known bugs and infelicities".

Existing tests tcfail149 and tcfail150 have been reenabled, and I added T7854 for the MultiParamTypeClasses case.

Trac metadata

Trac field	Value
Test case	→ typechecker/should_fail/T7854
Differential revisions	→ D688
Related	→ #10118 (closed), #10119 (closed)

Thomie, thanks for working on this. Inspired by your patches I can see a simpler way to achieve the same goal, so I'll do that.

Specifically I plan to do this:

• Fix the original bug simply by always doing a checkValidType on the entire selector-id type. That includes an ambiguity check which is precisely what we need.
• Implement the check when ConstrainedClassMethods is off as a special check that does nothing else.
• As ticket:7854#comment:71080 acknowledges, GHC has not been making the claimed check for ages. Rather than making ConstrainedClassMethods on by default (as you propose), I plan to make it implied by MultiParamTypeClasses, which means that we are out of Haskell-98 land anyway. This means that some programs may break, but (a) the error message suggests adding ConstrainedClassMethods (b) the fix is easy. If necessary (e.g. on a Stackage run) we can make it on-by-default in 7.10 to ease transition.

Commit coming. Thanks for unblocking this.

Simon

mentioned in commit f66e0e69

closed

OK done. I suggest we don't push this to 7.10 in case it breaks things.

Simon

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed
Test case	typechecker/should_fail/T7854 → module/mod39

mentioned in commit 3aa2519e

mentioned in commit 9dc0d63c

FWIW- This started breaking some pre-existing code:

https://hackage.haskell.org/package/semigroupoids-1.2.6/docs/src/Data-Functor-Alt.html#some

Would having FlexibleContexts imply ConstrainedClassMethods as well also be too much to ask?

Otherwise I'm going to have to start putting CPP around the set of directives for the module.

Replying to [ticket:7854#comment:97018 ekmett]:

Otherwise I'm going to have to start putting CPP around the set of directives for the module.

Why CPP? Afaik, {-# LANGUAGE ConstrainedClassMethods #-} is supported since GHC 7.0.1 ...

Herbert's point is a good one.

But it would not be impossible to make FlexibleContext also imply ConstrainedClassMethods, if that was vastly better.

Simon

It has been around for a long time, but I know at least a few of us were rather startled when we started getting error messages about it and every occurrence I've found so far is a module where I have FlexibleContexts already enabled.

Well, bugs (and this was a bug) are like that!

It's not so hard, and it is truthful, to add ConstrainedClassMethods to those libraries. But if the CLC advises, we can also make FlexibleContexts imply it.

Remember this is not in 7.10 so libraries have time to adapt.

Simon

That was me speaking as me, not in any official capacity. =) I had honestly thought FlexibleContexts was the extension for this sort of thing until now.

Putting on my CLC hat for a bit, the main reason I can see why it'd be nice to have FlexibleContexts "just work" is it means we don't have to make the hackage trustees go back and retrofit all sorts of old versions of packages with base upper bounds wherever they find themselves encountering this issue.

But mostly that rises to the left of "nice to have" not really "have to have".

Two thoughts

• I'm relaxed about what we choose here. It really matters little; and it's been a long-standing bug in GHC.
• You do have a point: that FlexibleContexts sounds as if it has to do with type-signature contexts (and it does); and so does ConstrainedClassMethods. So perhaps it would be more intuitive to make FlexibleContexts imply ConstrainedClassMethods than MultiParamTypeClasses?

But I bet there are packages that use MultiParamTypeClasses but not FlexibleContexts. So

• Perhaps we should try making FlexibleContexts imply ConstrainedClassMethods, but not MultiParamTypeClasses, just to see what happens.
• If it's painful, then maybe the path of least resistance is to make both imply ConstrainedClassMethods.

Any views from others? Would someone like to try the experiment?

Simon

mentioned in commit e4918034

mentioned in commit 7c2293a0

changed milestone to %8.0.1

Milestone renamed

mentioned in issue #11793 (closed)

added Pnormal label