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

[GHC]

#9590: AMP breaks `haskell2010` package
-------------------------------------+-------------------------------------
              Reporter:  hvr         |            Owner:  ekmett
                  Type:  bug         |           Status:  new
              Priority:  high        |        Milestone:  7.10.1
             Component:  Core        |          Version:  7.9
  Libraries                          |         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):

 There is no silver bullet here.

 The more I think on it, the more it strikes me that the best option is for
 us to just give up on these packages as a failed experiment.

 Neither hackage has ever really received any traction or picked up a
 coherent usage story. Every attempt folks (including me) have made to put
 forth them as something someone might use in practice has been rather
 rightly derided as unrealistic.

 We'd also get to clear `old-locale` and `old-time` out of the core.

 Any solution that involves bringing `Applicative` in could just as well be
 done outside of the GHC development process, so if a user base wanted to
 rally behind a `haskell98` / `haskell2010` package, it could be built out
 in `cabal` by anyone; we could put out a call for an active maintainer who
 wants to own it.

 It is only if we wanted to isolate `haskell2010` users further from the
 community by making them use their own `Monad`, etc. that we might have to
 keep `haskell2010` and `haskell98` as core packages -- but then only for
 compiler support for do sugar, and even that could probably be done with
 enough work. It doesn't strike me as a thing we're remotely ready to do
 though. It isn't clear it'd work sufficiently well for any appreciable
 number of users to at all justify the time and maintenance.

 Which brings us back to the option of just cutting these packages loose.

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