-
Notifications
You must be signed in to change notification settings - Fork 6
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
Record.Lens is not "completely compatible with lens" as claimed #20
Comments
I don't quite understand what the problem is here and what you propose. |
|
Probably he's complaining that the argument of For example, currently the type of In terms of compatibility, it'd be better to generalize these combinators. |
@fumieval my complaint would be solved if ghc could infer a rank-2-type. Your examples would not be solved if ghc could infer a rank-2-type. But they are both arguments for changing the types in Record.Lens. |
Okay I finally got @aavogt. I've been thinking about removing the "Record.Lens" module from the project altogether in future releases anyway, giving preference to the "basic-lens" dependency. Although that library provides exactly the same API as the one in the "Record.Lens" module, its documentation is more involved and does not contain the issues, which @aavogt mentioned. Concerning the "lens" compatibility, it was never intended to make the lens-combinators of the "record" library exactly compatible with the "lens" library, they were only meant to be interchangeable as per the purposes of the "record" library instead. The most important thing here is that the lenses produced with the |
Record.Lens uses RankNTypes when defining view/set etc. unlike Control.Lens, which means more type signatures are needed
The text was updated successfully, but these errors were encountered: