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 <dave@zednenem.com>
<http://www.eyrie.org/~zednenem/>