[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 goldfire):

 Replying to [comment:9 Mathnerd314]:
 > "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."

 Point well taken. I guess I was specifically referring to this passage
 from that page:

     Unjustifiable Costs: We support code in the upstream forever. Support
 is enormously expensive and takes up a huge amount of our time. The cost
 to support a change over its lifetime is often 10x or 100x or 1000x
 greater than the cost to write the first version of it. Many uncoordinated
 patches we receive are "white elephants", which would cost much more to
 maintain than the value they provide.

     As an author, it may look like you're giving us free work and we're
 rejecting it as too expensive, but this viewpoint doesn't align with the
 reality of a large project which is actively supported by a small,
 experienced team. Writing code is cheap; maintaining it is expensive.

 In an ideal world, the GHC maintenance would be democratized. But that's
 not quite how it currently is (there's a fairly small group that do the
 regular maintenance) and so we have to guard the door carefully. Part of
 the reason that insiders' ideas are seen more favorably is that, once
 you've demonstrated the time and energy to be a regular contributor, it
 seems more likely that you will maintain the patch -- at least for a
 while. This lowers the cost of accepting the patch.

 Shifting direction a bit, we really do need a more open, inclusive process
 by which ideas (even ones without proper specifications, yet) can be
 debated by the community, so that it's clearer what the community reaction
 is. You're going to get a very self-selected slice of the community by
 debating here. It sounds (from Simon's blog post linked earlier) that
 there is such a process in the works, and I'm looking forward to learning
 more about it.

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