Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10362 closed bug (fixed)

Make tuple constraints into a class

Reported by: simonpj Owned by:
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 7.10.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:


At the moment GHC treats tuple constraints specially. If you grep for TuplePred you'll see this. But the special treatment is strange; see the confusion between constraint tuples and ordinary tuples in #9858.

But I now realise that we can sweep away all this nonsense. Suppose we declare

module GHC.Classes where
  class    (c1, c2) => (,) c1 c2
  instance (c1, c2) => (,) c1 c2

  class    (c1, c2, c3) => (,) c1 c2 c3
  instance (c1, c2, c3) => (,) c1 c2 c3

and so on. (This is analogous the tuple data type declarations in GHC.Tuple.) Notice that:

  • GHC.Classes,(,) is a class, of kind Constraint -> Constraint -> Constraint.

quite distinct from GHC.Tuple.(,), whose kind is * -> * -> *.

  • GHC.Classes.(,) is a perfectly ordinary class, with no methods and two superclasses.
  • So all the usual superclass stuff applies.
    • If you have a given Ord a then you have a given Eq a (its superclass). Similarly if you have a given (,) c1 c2 then you also have given c1 and given c2`.
    • If you want to construct a dictionary of type Ord a (a "wanted"), you must supply a dictionary of type Eq a. Similarly, if you want to construct a dictionary of type (,) c1 c2 then you must supply c1 and c2.
  • I have written (,) c1 c2 to stress that there is a class GHC.Classes.(,), but we'll also allow the concrete syntax (c1,c2) instead.
  • Nevertheless the syntactic form (c1, c2) => blah is just sugar for c1 => c2 => blah (a type with two, curried constraints); it does not stand a type with a single constraint. Otherwise the instance
    instance (c1,c2) => (c1,c2)
    would be the identity function!

The key thing is that, aside from special syntax, (,) is a perfectly ordinary class, so we can simply delete all the special treatment of TuplePred. (Implicit parameters are also treated as a special class, incidentally.)

There should be no user-visible effects. But I think it would cure the worst aspects of #10359, as well as cleaning up TypeRep confusion.

Change History (3)

comment:1 Changed 4 years ago by simonpj

Resolution: fixed
Status: newclosed

This has been done, some time ago!

comment:2 Changed 4 years ago by thomie

Milestone: 8.0.1

comment:3 Changed 4 years ago by Iceland_jack

Affects error messages: #11386

Note: See TracTickets for help on using tickets.