#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