Open crabmusket opened 9 years ago
tonymorris
commented
9 years ago Eliminating lens is going to introduce a huge amount of boilerplate. It's just not obvious at the moment, because the code is not well-factored. I have never seen a project that does not benefit by use of lens. I am sceptical that this is an exception.
crabmusket
commented
9 years ago What's your opinion on TH? I assume makeLenses would remove all this?
tonymorris
commented
9 years ago Imagine if TH didn't exist for a minute. What is the score? It means there is a small amount of boilerplate in the creation of lenses, traversals, folds, etc. The benefit is large, but not particularly obvious at the code is currently stands. We'd have to write a few small, principled instances with the benefit of removing a large amount of other boilerplate.
Since TH does exist, and is used by lens library to remove the creation, what is the score now? It means we can use makeLenses and go even more general by using makeClassy. This would eliminate the boilerplate that is otherwise needed, while still retaining the benefits of removing the orthogonal boilerplate that the use of lens achieves.
However, it is possible to go even more general, by parameterising on the Optic instance. Template Haskell will not help here. I think there is a legitimate argument to be made; use Template Haskell, don't be so general. The downside is the pollution of namespacing and the introduction of additional problems with respect to abstraction.
I have written a small source file example here, demonstrating one benefit of abstracrting on the Optic instance. Less-trivial examples achieve greater benefits, but they are less obvious in small examples:
https://gist.github.com/tonymorris/295addabea718fe3b387
The key function is getLeft, which will work on "anything that has a Prism to a left-like thing." In this case, it works on both Or and These as well as Constant a (and then, any future left-like things). This means we can "add constructors to data types", without having to update usage functions such as getLeft. Or, in other words, The Expression Problem, which presents a known contention, has been solved in a way that wins (relatively) in all directions.
It is for these reasons, and others related, that I prefer to abstract on the Optic, implement the hand-written code and achieve significant benefits out the other side. I agree these benefits are not yet being exploited. I intend to change this though.
crabmusket
commented
9 years ago Okay, thanks for the detailed response. I'm not sold yet, but I'll wait and see how it goes. For now I will maintain a more 'beginnery' branch that I can grok haha.
Let's discuss Lens. IMO the library is overkill for almost all projects, but I haven't used it yet so maybe I'm just not yet sold on the benefits.
@tonymorris what I propose is that since Lens is adding a significant amount of boilerplate currently, why don't we try to implement everything without it, when make a branch, add Lens, and see what wins we get?