Opened 13 months ago

Closed 12 months ago

Last modified 12 months 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: Cc: ekmett@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Hi,

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 (13)

comment:1 Changed 13 months 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 13 months 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 13 months 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 13 months 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 12 months 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 12 months 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 12 months ago by thoughtpolice

  • Milestone set to 7.8.1
  • Version changed from 7.6.3 to 7.8.1-rc1

comment:8 Changed 12 months 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
Data.Proxy.

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 <[email protected]>

comment:9 Changed 12 months ago by thoughtpolice

  • Status changed from new to merge

comment:10 Changed 12 months 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 12 months 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 12 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from merge to closed

Merged in 7.8 for RC2.

comment:13 Changed 12 months ago by Herbert Valerio Riedel <hvr@…>

In 44dec750a618a89202f80dcd695e5eb9fb74a74f/base:

Tweak documentation and update changelog.md

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 <[email protected]>
Note: See TracTickets for help on using tickets.