[GHC] #9590: AMP breaks `haskell2010` package

[GHC]

#9590: AMP breaks `haskell2010` package
-------------------------------------+-------------------------------------
              Reporter:  hvr         |            Owner:
                  Type:  bug         |           Status:  new
              Priority:  high        |        Milestone:  7.10.1
             Component:              |          Version:  7.9
  libraries/haskell2010              |         Keywords:  AMP
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  GHC         |  Related Tickets:
  rejects valid program              |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by ekmett):

 The fact that the AMP broke strict Haskell2010 compatibility for the
 `haskell2010` package was a known going in. We already broke it with `Num`
 a few years ago.

 We really have two options going forward.

 We can say that `haskell2010` and `haskell98` and the like are what they
 are, rough compatibility shims that get you as close as we can to the
 semantics of those standards without breaking compatibility with other
 packages...

 Or we can sink more effort into making them more accurate to their
 corresponding standards but in the process doom any code that bothers to
 compile with them to second-class citizen status.

 I'm rather ambivalent about the choice we make here.

 So the question comes down to: who is the audience of `haskell2010` the
 package?

 Is it educators who want a given standard they can teach to? Folks who
 have students who mayl eventually cast off the training wheels and move on
 to write real GHC if they want to build code that fits with the rest of
 the ecosystem?

 Or is it users who don't want to let a GHC monoculture set the standard
 and would prefer to work with a smaller subset of the language, but still
 want to have access to the ecosystem of packages through cabal? Folks who
 may have other compilers in mind, who would prefer to implement against a
 standard or at least have the ability to have their code compile against a
 compiler that implements the standard.

 If it is the former, then the story of making haskell2010-specific `Monad`
 and `Num` classes with their own supplies of instances has some merit.

 If it is the latter, we'd cripple the ability of that group to work with
 both packages to make `haskell2010` and `haskell98` export their own
 version of `Monad` and `Num`.

 I'm personally inclined to go with the status quo, which is that
 `haskell2010` is a fairly weak compatibility shim that more directly suits
 the needs of the second audience, if only because it is the audience who
 can grow the most, and it takes the least amount of effort investiture on
 our behalf.

 If, however, a champion were to stand up and offer to do all the work to
 maintain a more pedantic `haskell2010` package replete with its own
 instances for its own `Monad` / `Num`, I wouldn't stand in their way.

 Frankly, as it stands that could probably be done as an end user project
 without really involving any input from GHC HQ.

 If that were done it needn't even conflict with the existing `haskell2010`
 package.

 So, with that in mind I'd be content to see the existing package for what
 it is, and push back the effort to make a better shim on the user who
 actually wants to confront all the issues involved.

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