[Haskell-cafe] Lenses and records and ecosystem

[David Menendez]

On Tue, Feb 14, 2017 at 4:36 AM, Anthony Clayden <
anthony_clayden at 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 at zednenem.com>
<http://www.eyrie.org/~zednenem/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170214/9acfd3fc/attachment.html>