<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 26, 2015 at 5:00 PM, Dan Gudmundsson <span dir="ltr"><<a href="mailto:dangud@gmail.com" target="_blank">dangud@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Maybe a stupid question I have not looked at lenses before </div>but why include the "path of keys" into the lens?</blockquote></div><br></div><div class="gmail_extra">My guess is that requiring a Key breaks some trivial lenses, or adds some complexity to the proofs. You can create an identity lens for instance:<br><br></div><div class="gmail_extra">lens_id() -><br></div><div class="gmail_extra">    {fun(X) -> X end, fun(A, _X) -> A, ...}.<br><br></div><div class="gmail_extra">which should obey the lens laws. Furthermore it composes as an identity does, i.e.<br><br></div><div class="gmail_extra">compose(ID, Lens) == Lens<br></div><div class="gmail_extra">compose(Lens, ID) == Lens<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">It could be, I haven't really checked, that the requirement of a Key poses additional complexity here. Lenses stems from languages which have currying, so you can simply partially apply the key to obtain the closure which can process that Key. By doing so, the Key kind-of gets out of the way, which probably makes identities as the above fall out nicer in the logic, and currying can be used to elegantly "hide" the fact that there are keys in there over which we have built a closure.<br><br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">J.</div>
</div></div>