[GHC] #9948: Recommend class constraint instead of instance constraint

GHC ghc-devs at haskell.org
Mon Jan 5 15:24:14 UTC 2015


#9948: Recommend class constraint instead of instance constraint
-------------------------------------+-------------------------------------
        Reporter:  crockeea          |                   Owner:
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.8.4
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by goldfire):

 I'm -1 on this change.

 * `Num a` is the minimal constraint (in a logic sense) needed on `f`, as
 it implies all other constraints necessary.

 * Point (2) above talks about robustness in the presence of refactoring.
 While that case is true, other refactorings (say, splitting up the `Foo`
 class) prefer the `Num a` constraint.

 * Implementing this would be ''more'' work for GHC, I believe. When GHC is
 trying to satisfy the `Foo a` constraint that arises from the use of
 `foo`, it then naturally looks for `Foo` instances. It finds a matching
 one, and then proceeds to try to satisfy the instance's constraints. This
 process can continue arbitrarily deeply. To report the error requested
 would require, at the end, looking at the set of unsolved constraints and
 then trying to find some instance that covers them all. There might be
 more efficient/effective ways to do this (say, remember precisely the
 constraints that arise directly from constrained function usages), but it
 would be more work for GHC, regardless.

 As a smaller point (but which confused me at first), the original post
 uses the term "superclass" in a way different to the way I use it: I've
 always understood "superclass" to refer to constraints on a class
 definition, such as the `Bar a` in `class Bar a => Fuggle a`. Above, it
 seems the term "superclass" refers to an instance head. Please correct if
 I'm wrong.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9948#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list