search

bgamari / monoidal-containers

Maps using values' monoidal structure during merging
Other
42 stars 33 forks source link

Should `monoidal-containers` split into `lens` and `these` subpackages? #75

Open emilypi opened 3 years ago

emilypi commented 3 years ago

Related to https://github.com/bgamari/monoidal-containers/issues/73 is the idea that monoidal-containers should not bring in the these (lower dep footprint) or lens (higher dep footprint) universes. Rather, it would be nice to punt them to subpackages like these-lens so that the underlying core newtypes + api can be used in other packages without having to inherit the footprint. I would like to build upon this library if possible, but lens is a non-starter my project. It would make #73 much cleaner as well.

Thoughts?

endgame commented 3 years ago

Modern versions of these have a very tiny dep footprint, so you'd be defining instances on classes provided by semialign. Which doesn't have a particularly large dep footprint either now that indexed-traversable exists. I have no objection to lens in my projects, but I think a separate package that exports instances for things in large-footprint packages like lens is probably a good idea.

I mean, the better idea is to go back in time and put the good Monoid instances into containers.

adamgundry commented 2 years ago

I would also like to see lens instances moved to a separate package. (I tripped over this by trying to compile ghc-debug-brick and wondering why it was pulling in no fewer than two lens libraries...)