On Tue, Feb 14, 2017 at 4:36 AM, Anthony Clayden < anthony_clayden@clear.net.nz> wrote:
On Sat, Feb 11, 2017 at 21:04, David Menendez wrote:
Lenses (and their relatives) transform operations, not values.
So it must be a stubborn superstition on my part that getting/putting from/to structures is about values.
I don’t understand what you mean. Ultimately, the operations that you use with lenses are all about retrieving or modifying values.
I'm not here to 'knock' lenses (of whichever model), but every time I scratch the surface, the answers wander off into category theory and higher-order types.
I’ll agree that the internal structure of lenses is pretty involved, and there are some historical design decisions that arguably make them more complicated than necessary, and that keeping compatibility between the various flavors of lens-like things prevents hiding those details from the user. I’m not sure who’s bringing category theory into the discussion. I don’t know that it has much to say about lenses and lens-like things.
I'll draw a comparison with another place in Haskell where category theory has huge benefits: monads.
There's less than a handful of operators for monads, and those are conveniently handled behind some elegant syntactic sugar (do-notation).
So a newbie doesn't really need to grok monads. They can get on and use them; learn the theory later.
Can that be said of lenses?
Reasonable people can disagree about the operators in the lens package, but the only one you really need is (.), which comes from the prelude. Everything else has a named function equivalent.
I guess part of the trouble is that H98 record operations have gobbled up so much of the syntactic design space.
Nevertheless I don't see what syntactic sugar could help with lenses.
Composition of lenses is exactly like composition of functions, with the inner-most operation on the right.
That doesn't seem to say more than "it's composition". If I want to get a foo out of a bar out of a baz in a s, I'd (perhaps naievely) go
foo (bar (baz s)) -- i.e. (foo . bar . baz) s
And I'm using function application all the way through.
Lenses are not functions that retrieve values from structures, but they can be used to create those functions. If you had written (view foo . view bar . view baz) s, that would be okay.
Lenses do not use function application of the lens to the structure. You need an extra operator (view, over).
Exactly.
Then I'm not seeing the syntactic merit of using composition (.) for lenses.
The power of the lens package is that it uses a common functional representation across a spectrum of lens-like things, ranging from widely-applicable (Fold) to highly-flexible (Iso), all of which can be sensibly composed using function composition.
It's certainly making the mental machinery incompatible for lenses vs records, even if they can co-exist semantically.
How so? Records don’t use (.) at all.
A lens foo :: Lens O I transforms an operation on I into an operation on O. A composition outer.inner turns an operation on the target of inner into an operation on the source of outer.
This is demonstrated by the way over distributes with (.):
over (outer . inner) = over outer . over inner
What confuses people is view, which is contravariant:
view (outer . inner) = view inner . view outer
but you can't avoid having one of over and view be contravariant.
OK. (Why did it need so much category theory to explain that?)
What category theory did I use?
And why do those nifty equivalences have to intrude so much into the surface syntax, just to get a value out of a structure?
What do you mean?
If all you want to do is retrieve a value from a structure, you can just
use simple functions. The whole point of lenses is that they do more than
that.
--
Dave Menendez