Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#8797 closed feature request (fixed)

Generics instances for monoid and applicative newtypes

Reported by: jcristovao Owned by:
Priority: normal Milestone: 7.8.1
Component: libraries/base Version: 7.8.1-rc1
Keywords: Generics Cc: ekmett@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:



Is there any particular reason why there aren't Generic instances for the newtypes under Data.Monoid and Control.Applicative (for example)?

I've tried adding them to GHC/Generics.hs and base compiles without problems.

Could this addition be considered? Best Regards, João

Change History (14)

comment:1 Changed 6 years ago by dreixel

StandaloneDeriving can be used to get these instances in user code, but I don't see a reason why they shouldn't be provided directly where the type is defined.

comment:2 Changed 6 years ago by simonpj

Cc: ekmett@… added

I guess this is a library issue. Edward and the core library committee, over to you.

comment:3 Changed 6 years ago by jcristovao

StandaloneDeriving can be used

Yes, of course, but there is always the (increased) risk of two libraries using it, and thus having Duplicate instance declarations. I would say its safer to include this in base.

comment:4 Changed 6 years ago 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.

comment:5 Changed 6 years ago by ekmett

FWIW- The committee is in favor of adding the Generic, Generic1, Data and Typeable instances along with Num for Sum and Product.

Do we want to try to pester Austin at the 11th hour to add them to the 7.8 release candidate or hold off a year for 7.10?

The former has the benefit of, well, being a year sooner, but it may be that that ship has already sailed.

Moreover, it'd means you can't write code that needs those instances and which works with both the 7.8.1-release candidates and the final release.

On the other hand, once we have 7.8.1 the release candidates will have done their job and will be a non-issue.

At this point I defer to Austin about the viability of packaging it up now or if we should wait.

comment:6 Changed 6 years ago by thoughtpolice

After reviewing with Edward, these changes are so trivial and obvious that I'll push them in with a small set of patches today.

comment:7 Changed 6 years ago by thoughtpolice

Milestone: 7.8.1

comment:8 Changed 6 years ago by Austin Seipp <austin@…>

In 1a9abe7a1a3c77a028cf23640368cb45527d5834/base:

Add some instances for Monoid/Applicative (#8797)

As noted in the ticket, there's no particular reason why there aren't
Generic, Typeable, and Data instances for the types in the
Monoid/Applicative modules.

Furthermore, Product and Sum should also have Num instances as well as
Edward noted.

Aside from that, this patch also changes the dependency chain slightly -
it moves the Monoid Proxy instance into Data.Monoid and out of

Why? Cycles (of course). Monoid depends on Typeable. Typeable uses
Proxy. Proxy uses Monoid. Boom. Luckily, Proxy only depends on Monoid
outside of the GHC namespace, so the fix is easy and clean.

Signed-off-by: Austin Seipp <>

comment:9 Changed 6 years ago by thoughtpolice

Status: newmerge

comment:10 Changed 6 years ago by jcristovao

I'm _very_ glad that this is being pushed to 7.8. Really good news.

For my particular use case these are good enough, but if I might push the envelop, why stop here? I'm certain some modules are more dificult than others, due to dependency cycles, but (and withouth checking for that, just from a quick round up), why not include these:

Control.Arrow: Kleisli, ArrowMonad Data.Fixed: Fixed, E0, E1, ... Data.Unique: Unique Data.Traversable: StateL, StateR, Id Data.Ord: Down System.Timeout: Timeout

Also for Generic, Generic1, Data.

If easy enough (i.e., no hard dependencies), it might be useful to someone else.

Just a though, Thanks

comment:11 Changed 6 years ago by thoughtpolice

We should open a separate ticket for these I think. Edward I'm sure will agree that we need to look out for adding more sensible instances for the types in base (we always seem to forget some, somewhere).

comment:12 Changed 6 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed

Merged in 7.8 for RC2.

comment:13 Changed 6 years ago by Herbert Valerio Riedel <hvr@…>

In 44dec750a618a89202f80dcd695e5eb9fb74a74f/base:

Tweak documentation and update

This adds release note entries to changelog and tweaks Haddock comments
with respect to the recent commits 1a9abe7a1a3c7 (re #8797) and
f932b79948f0 (re #8745)

Signed-off-by: Herbert Valerio Riedel <>

comment:14 Changed 3 years ago by RyanGlScott

Keywords: Generics added
Note: See TracTickets for help on using tickets.