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

Remove dependency on lens #1

Open
tonymorris opened this issue Feb 17, 2015 · 8 comments
Open

Remove dependency on lens #1

tonymorris opened this issue Feb 17, 2015 · 8 comments

Comments

@tonymorris
Copy link
Contributor

It would be nice to remove the dependency on the lens package and use smallerpackages such as profunctors. Unfortunately, this means foregoing the Swapped instances.

Discussion on this issue is here:
ekmett/lens#526

@gwils
Copy link
Collaborator

gwils commented Oct 10, 2017

I don't think the benefit of removing the lens dependency outweighs the usefulness of the Swapped instance.

@recursion-ninja
Copy link
Contributor

Since Cabal 3.0 allows for multiple libraries to be exported from a package, we could split the dependencies up into two exposed libraries.

validation would not depend on lens and forgo the Swapped instance.
validation:lens would depend on lens and additionally expose a Swapped instance.

Users of the Library would have to import two modules to use the Swapped instance, say something like:

Data.Validation
Data.Validation.Lens

where the first module is exposed by validation and the second module is exposed from validation:lens.

The advantage of this approach is that if a user want to use the Validation type but does not need the Swapped instance, they can have their project depend on only the validation package and not also the validation:lens package, which allows their project to avoid the transitive dependency on lens.

@gwils
Copy link
Collaborator

gwils commented Jan 5, 2020

Unfortunately that would make instance Swapped Validation an orphan instance (as would having it in a separate cabal package).

@recursion-ninja
Copy link
Contributor

You're not wrong. Would that really be a problem since all instances for the Validation type originate from libraries of the validation package? Philosophically, it seems fine to me.

There's always some trade-offs to be made. I think the orphan instance(s) are a minor triviality and the convenience for the library consumer is major win. I greatly wish more packages did this so that I could opt out of depending on lens and aeson when my project uses neither of them.

@tonymorris
Copy link
Contributor Author

I think the penalty of orphan instances is very high and to be avoided. If something as trivial as depending on lens resolves this penalty, then I think it is a reasonable solution.

@kindaro
Copy link

kindaro commented Jan 25, 2020

@tonymorris A dependency on lens is not trivial. lens is a dividing line between two «ecosystems», two coding styles, and two vastly separated levels of expertise. Validation as an idea is simple, clear, «mathematical» and, so to say, «should be in base». But any number of people will avoid it just to stay away from the «kmettosphere». Not to mention crazy build time. So, the minor convenience of Swapped without orphan instances should be weighed against people and projects being excluded from the user base.

@kindaro
Copy link

kindaro commented Jan 25, 2020

I took the liberty of making a fork without any lens stuff. I will see if it works for me. I would prefer a more moderate edit, but this is the best I have time for.

@aloussase
Copy link

Couldn't the lens dependency be moves to another package that uses the same modules? So that users can opt-in for the Swappable instance.

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

5 participants