<div dir="ltr">On Tue, Feb 14, 2017 at 4:36 AM, Anthony Clayden <span dir="ltr"><<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> On Sat, Feb 11, 2017 at 21:04, David Menendez wrote:<br>
<span class="gmail-"><br></span><span class="gmail-">>  Lenses (and their relatives) transform operations, not<br>
values.<br>
<br>
</span>So it must be a stubborn superstition on my part<br>
that getting/putting from/to structures is about values.<br></blockquote><div><br></div><div>I don’t understand what you mean. Ultimately, the operations that you use with lenses are all about retrieving or modifying values.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'm not here to 'knock' lenses (of whichever model),<br>
but every time I scratch the surface,<br>
the answers wander off into category theory<br>
and higher-order types.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'll draw a comparison with another place in Haskell<br>
where category theory has huge benefits: monads.<br>
<br>
There's less than a handful of operators for monads,<br>
and those are conveniently handled behind some elegant<br>
syntactic sugar (do-notation).<br>
<br>
So a newbie doesn't really need to grok monads.<br>
They can get on and use them; learn the theory later.<br>
<br>
Can that be said of lenses?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I guess part of the trouble is that H98 record operations<br>
have gobbled up so much of the syntactic design space.<br>
<br>
Nevertheless I don't see what syntactic sugar could help<br>
with lenses.<br>
<span class="gmail-"><br>
> Composition of lenses is exactly like composition of<br>
functions, with<br>
> the inner-most operation on the right.<br>
<br>
</span>That doesn't seem to say more than "it's composition".<br>
If I want to get a foo out of a bar out of a baz in a s,<br>
I'd (perhaps naievely) go<br>
<br>
    foo (bar (baz s)) -- i.e.<br>
    (foo . bar . baz) s<br>
<br>
And I'm using function application all the way through.<br></blockquote><div><br></div><div>Lenses are not functions that retrieve values from structures, but they can be used to create those functions.</div><div><br></div><div>If you had written (view foo . view bar . view baz) s, that would be okay.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Lenses do not use function application of the lens to the<br>
structure.<br>
You need an extra operator (view, over).<br></blockquote><div><br></div><div>Exactly. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Then I'm not seeing the syntactic merit of using<br>
composition (.) for lenses.</blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It's certainly making the mental machinery incompatible<br>
for lenses vs records, even if they can co-exist<br>
semantically.<br></blockquote><div><br></div><div>How so? Records don’t use (.) at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-">> A lens foo :: Lens<br>
> O I transforms an operation on I into an operation on O. A<br>
> composition outer.inner turns an operation on the target<br>
> of inner into an operation on the source of outer.<br>
><br>
> This is demonstrated by the way over distributes with (.):<br>
><br>
>     over (outer . inner) = over outer . over inner<br>
><br>
> What confuses people is view, which is contravariant:<br>
><br>
>     view (outer . inner) = view inner . view outer<br>
><br>
> but you can't avoid having one of over and view be<br>
> contravariant.<br>
<br>
</span>OK. (Why did it need so much category theory to explain<br>
that?)<br></blockquote><div><br></div><div>What category theory did I use?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And why do those nifty equivalences have to intrude so much<br>
into the surface syntax, just to get a value out of a<br>
structure?<br></blockquote><div><br></div><div>What do you mean?</div><div><br></div><div>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.</div><div><br></div></div>-- <br><div class="gmail_signature">Dave Menendez <<a href="mailto:dave@zednenem.com" target="_blank">dave@zednenem.com</a>><br><<a href="http://www.eyrie.org/~zednenem/" target="_blank">http://www.eyrie.org/~zednenem/</a>></div>
</div></div>