Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split this package #166

Open
treeowl opened this issue Dec 3, 2017 · 1 comment
Open

Split this package #166

treeowl opened this issue Dec 3, 2017 · 1 comment

Comments

@treeowl
Copy link

treeowl commented Dec 3, 2017

Some if not all of the .Class modules have very few dependencies. For example, Control.Monad.Free.Class only depends on transformers. But depending on free means pulling in profunctors, semigroupoids, and so on.

@ekmett
Copy link
Owner

ekmett commented Apr 26, 2018

This proposal isn't without real costs.

Splitting the package up makes it harder to iterate on across the boundary.

It makes it slightly harder for users to use as users now need to import two packages, or we have to re-export modules.

And it makes it harder to discover your way around as with the classes in the file its easy to see all of the instances of MonadFree in the haddocks. If the class is in another package they won't get that summary.

I'm inclined to treat this as a WONTFIX feature request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants