1. You can already do what you want, if you rephrase your instance. From
#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]: the initial post:
{{{#!hs instance (a ~ Int, b ~ Char) => C a b where ... }}}
Phabricator has well-written reasons why; see "Rejecting patches" on [https://secure.phabricator.com/book/phabcontrib/article/contributing_code/
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." 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