#12358: Read1/Read2 don't have methods defined in terms of ReadPrec -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: core-libraries-committee@… (added) Comment: Sorry, I should know by now to forward the CLC on things like this, seeing as how I'm on the CLC myself :) For now, I only have the above [https://mail.haskell.org/pipermail/libraries/2016-June/027102.html mailing list discussion] as evidence that this move is supported by the community. Anyways, adding `Read1` and `Read2` was decided in #11135 (associated mailing list discussion [https://mail.haskell.org/pipermail/libraries/2015-July/026014.html here]). `Read1/2` were originally defined in `transformers`, but migrated to `base` as part of an effort to bring in `Compose`/`Sum`/`Product`/`MonadIO` (and remove things from `transformers` that aren't actually, y'know, monad transformers). Ross's original definition of `Read1/2` uses `ReadS`, since that's what the report [https://www.haskell.org/onlinereport/basic.html#sect6.3.3 dictates] the definition of `Read` should use, so that's what was migrated to `base`. It didn't occur to me at the time the problems that would pose when I began to work on [https://github.com/haskell-compat/deriving- compat/issues/3 automatic derivation] of `Read1/2` instances, since GHC's derived `Read` instances use `ReadPrec` instead of `ReadS`. This ticket just serves as a way to make the methods of `Read1/2` parallel to those of `Read`, and to eventually make deriving `Read1/2` easier. (P.S., if you're curious about whether kind polymorphism can obviate the need for multiple `Read(n)` classes, you might be interested in the discussion [https://github.com/haskell/deepseq/issues/8 here]. phadej has proposed one way to solve such a problem, although it involves some eyebrow-raising `-XTypeInType` tricks.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12358#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler