#8797: Generics instances for monoid and applicative newtypes -------------------------------+------------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.6.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by ekmett): I personally have no objection and think it'd be a good idea. The `Generic` and `Generic1` instances clearly belong with their definitions. They also deserve `Typeable` and `Data`. Forcing the user to supply them risks conflicting orphans, making Haskell libraries less composable and there is no real data hiding argument to be made about transparent newtypes from base. I'll definitely put it to the committee and see what they think. In particular, while these 4 seem pretty obvious to me, there are some data types in there that could really use a few other instances as well. e.g. the fact that there is no `instance Num a => Num (Sum a)` or `instance Num a => Num (Product a)` is something I hear fairly regular complaints about in #haskell and none of the various reimplementations on hackage do anything but the obvious. Those start to speak to changing the suggested usage of these monoidal wrappers from something you 'put on long enough to foldMap' to something your data might live in long-term, but looking around that is what folks are actually doing. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8797#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler