[GHC] #12240: Common Sense for Type Classes

[GHC]

#12240: Common Sense for Type Classes
-------------------------------------+-------------------------------------
        Reporter:  Mathnerd314       |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Mathnerd314):

 Replying to [comment:8 goldfire]:
 > 1. You can already do what you want, if you rephrase your instance. From
 the initial post:
 >
 > {{{#!hs
 > instance (a ~ Int, b ~ Char) => C a b where ...
 > }}}
 >
 Sure, this works for the original, and the original can also be solved
 with functional dependencies (as in comment:3). Even the example in
 comment:4 could be done with equality constraints, `(a ~ Int) => instance
 C a Bool` and so on. The issue is the open-world problem; with such
 general instance heads, you cannot extend the class to have more instances
 without running into overlap problems. Whereas with my approach, instances
 can still be declared; they just mean that instance resolution will fail
 more often (which is already an expected side-effect of declaring
 instances).

 From what I can tell, there was no reason for the matching (instead of
 unifying) behavior to begin with; it was just "how type class matching
 worked", back in 1996. E.g. page 12 of
 https://courses.cs.washington.edu/courses/cse590p/06sp/multi.pdf mentions
 that matching uses one-way unification, but gives no explanation of why
 two-way unification was not chosen. Then on page 13 they state that
 constraints can be improved if they unify with a unique instance, but just
 say "it is not yet clear if it would improve enough useful programs to be
 worth the extra effort."

 > Phabricator has well-written reasons why; see "Rejecting patches" on
 [https://secure.phabricator.com/book/phabcontrib/article/contributing_code/
 this page].

 "The Phabricator upstream is Phacility, Inc. We maintain total control
 over the project and roadmap. There is no democratic process, voting, or
 community-driven decision making. This model is better at some things and
 worse at others than a more community-focused model would be, but it is
 the model we operate under."

 I am not sure this describes GHC well; wiki:TeamGHC states "GHC's
 development as a whole is not led by any particular group, company, or
 individual."

 > At the moment, the original poster has gotten other member of the
 community to say that they wouldn't actively block the implementation of
 your idea; I'm afraid this is hardly a ringing endorsement.

 My impression is that this is better than the reaction to other
 (implemented!) proposals, e.g. Foldable in the Prelude, which were
 actively opposed. This issue is a rather small, dark corner of the
 language, so few have the patience to discuss it. Furthermore, I have not
 really elaborated on my proposal, because I don't know enough of GHC
 internals to describe it accurately, so it is hard to actively support a
 nebulous concept. At least a patch can be judged on its merits.

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