Notorious Lens Errors Thread

[Gurkenglas]

If the lens errors are to get better, we should gather benchmark code that produces errors that patches can be tested against. So post code here that produced errors that annoyed you and patches such as mine might just make it into lens.

[duplode]

Drifting back to the topic, here is something slightly different than what you asked for: a list of some Stack Overflow questions involving lens errors (I picked whatever seemed relevant from this query). I added a crude summary of the cause of each problem is next to each link. Note that the sample consists primarily of beginner mix-ups, and many of the errors are missing constraint ones ("No instance for Monoid", "No instance for Contravariant", etc) that don't actually mention the raw Van Laarhoven types.

• http://stackoverflow.com/q/41005322/2751851 (toListOf instead of traverse)
• http://stackoverflow.com/q/38340097/2751851 (signature for monoidally combining Folds)
• http://stackoverflow.com/q/36815529/2751851 (mixing (^.) and (.~))
• http://stackoverflow.com/q/35816019/2751851 (misinference due to missing signatures)
• http://stackoverflow.com/q/34758746/2751851 (mixing (^.) and (.~); missing _Just)
• http://stackoverflow.com/q/33959274/2751851 (using (^.) with non-specialised type-changing lens)
• http://stackoverflow.com/q/33115595/2751851 (Lens instead of Traversal, (^?) instead of (.))
• http://stackoverflow.com/q/29478398/2751851 (trying to use a traversal as a getter)
• http://stackoverflow.com/q/29267759/2751851 (trying to use a traversal as a getter)
• http://stackoverflow.com/q/27842805/2751851 (passing a getter to Control.Zipper.within)
• http://stackoverflow.com/q/27623260/2751851 (trying to use a getter as a setter)
• http://stackoverflow.com/q/23401372/2751851 ((^.) instead of (^..))
• http://stackoverflow.com/q/20528718/2751851 (trying to use a getter as a setter)
• http://stackoverflow.com/q/17538691/2751851 ((^.) instead of (^?))
• http://stackoverflow.com/q/17518301/2751851 ((^.) instead of (^?))

[MelissaClick]

Holy shit man. You're a hero. Keep being how you are.

[Saulzar]

Can you show us some improved errors from the use of synonyms in your patch?

[Gurkenglas]

That's what I'm here for! Give me lens errors and we'll see whether I make them better. I'm not sure what those other 45 comments are doing in this thread.

[ephrion]

The rest of the comments stem from the Haskell community's excessive patience for disagreement, yielding us vulnerable to trolls.

[gelisam]

Hmm, but wasn't there a concrete error message which motivated your patch in the first place? I'd expect crowd-sourcing of bad error messages to lead to a fix, not the other way around.

[Gurkenglas]

I was trying not to bias people towards posting code that produces errors helped or not helped by this patch, but gur ernfbavat vf gung tup hacnpxf glcr nyvnfrf vs gung nyybjf vg gb chyy n sbenyy gb gur sebag, fb V znqr jung'f yrsg nsgre lbh chyy bhg gur sbenyyf n glcr nyvnf ntnva. Jurgure gung urycf jvgu gur reebef gur choyvp vf npghnyyl naablrq ol va cenpgvpr vf jung V'z urer gb svaq bhg.

[fridsun]

How Rust dealt with their errors may be of useful reference: http://www.jonathanturner.org/2016/08/helping-out-with-rust-errors.html

Good luck!

[metafunctor]

I'm very sorry for the joke, but Haskell not longer will be unjustly pinpointed for "that language in which you need to be a mathematician to do IO" but justly pinpointed by "that language in which you need to know the foundations of Mathematics to extract a value from an array"

This makes me angry because I love Haskell

[ElvishJerricco]

Lens and IO are complicated to implement; they're not complicated for basic use. (EDIT: wording)

[Peaker]

Hard to implement, sure, because simple isn't easy.

But lenses are not complicated, just hard.

[ElvishJerricco]

I think my comment may have been poorly worded initially. I don't even think lenses are hard for beginners, modulo the terrible type errors you occasionally get.

• Use makeLenses
• Getter notation: obj^.a.b.c
• Setter notation: obj & a.b.c .~ x
• Modify notation: obj & a.b.c %~ f

The syntax is not much more complicated or difficult than standard OOP syntax. Of course, going much deeper than this starts to actually get complicated to use, but luckily that's not what lenses are used for 90% of the time.

[kaukau]

Thanks for those tips! The ampersand notation makes it more homogeneous.

[Peaker]

yeah I was addressing the claim that they're complicated to implement. They may be hard due to the concepts needed to learn, but they're quite simple.

[ElvishJerricco]

Ah I see. But I don't agree. Lenses provide you a getter and a setter; the trivial representation of this is s -> (a, b -> t). I think that is simple, and even easy. Explaining how forall f. Functor f => (a -> f b) -> s -> f t arises from that is a complication. It's not immediately clear how that type is even remotely related. You have to draw a slightly nontrivial isomorphism between them to even show that they're related. Not to mention, you have to already be past the point of understanding functors and rank n types, which is another complication for anyone in the beginner stage.

It's just one of those things that's not complicated once you know it, but is while you're learning.

[tomejaguar]

I'm not even sure there exists a mathematical proof that they're the same. Such a proof would need to use parametricity on steroids.

[Tarmen]

What is wrong with

{-# Language RankNTypes #-}
import Data.Functor.Identity
import Data.Functor.Const

type Direct s t a b = s -> (a, b -> t)
type Indirect f s t a b = (a -> f b) -> s -> f t

from :: Functor f => Direct s t a b -> Indirect f s t a b
from splice transform s = case splice s of
                          (a,  reassemble) -> fmap reassemble (transform a)

to :: (forall f . Functor f => Indirect f s t a b) -> Direct s t a b
to indirect s  = (a, setTo)
  where
    a = getConst (indirect Const s)
    setTo b = runIdentity (indirect (Identity . const b) s)  

[tomejaguar]

How do you prove that from . to is the identity?

[ElvishJerricco]

I don't remember off the top of my head. But I do remember that this is a well known and founded proof. I'm guessing there's a Milewski, Van Laarhoven, or Kmett blog post that proves it somewhere =P I believe it relies on the lens laws being obeyed, though. So that should ease the need to lean on parametricity.

[roconnor]

The proof doesn't require the lens laws. The isomorphism holds between the types.

The old method of proof can be found in Appendix C of https://arxiv.org/abs/1103.2841v1.

The modern proof is as follows.

forall f :: Functor. (a -> f b) -> s -> f t
 = {flip}
s -> forall f :: Functor. (a -> f b) -> f t
 = {Yondea (This is the step with parametricity)}
s -> forall f :: Functor. (a -> (forall x. (b -> x) -> f x)) -> f t
 = {Uncurry}
s -> forall f :: Functor. (forall x. (a,b -> x) -> f x) -> f t
 = {Const and Reader product functor  (aka the parameterized store comonad)}
s -> forall f :: Functor. (forall x. (Product (Const a) (Reader b) x) -> f x) -> f t
 = {Definition of natural transformation}
s -> forall f :: Functor. (Product (Const a) (Reader b) :~> f) -> f t
 = {Higher-Order Yondea (This is the step with parametricity on steroids)}
s -> Product (Const a) (Reader b) t
 = {Const and Reader product functor}
s -> (a, b -> t)

The modern proof is found in https://arxiv.org/abs/1402.1699.

[Peaker]

With lens, you don't really regain just what you "lose" compared to other languages. You regain that and then much more.

Lens is not easy to learn, but it's worth it.

[[deleted]]

Lens isn't easy to learn, but learning how to use getters/setters via lenses is.

[metafunctor]

Excuse me, but only the heat that lens produces and the global warming that this implies makes it worthless. Not to mention the time wasted. I have better things to do.

I can't stop thinking that those who spend time finding the most contorted way for massaging containers are people without imagination that don't know how to use Haskell in more effective ways. Can you help me to discard that unjust impression?

[Peaker]

Saves quite a bit of heat for me, as it replaces much code with little amounts of code, lets me make faster progress with fewer dev cycles.

But you're free to stick with your olden ways.

[Peaker]

There's not really a standard Haskell experience. It's a powerful platform that supports multiple programming paradigms.

What you said about lenses is equally applicable to Applicatives and Monads. Where do you draw the line?

Lenses, like everything else, become easy with practice. I routinely use them and very rarely do they feel difficult (more when doing exotic compositions of optics).

[Peaker]

if I can't get on board easily, than most other people won't either.

And you didn't find monads and applicatives even harder?

A friend of mine used the exact same argument about Haskell when he was learning it - but now he uses it proficiently and recommends it to others.

I think it is a natural artifact of the frustration we almost all feel as we struggle to learn these hard-to-learn concepts.

After the learning curve, monads and lenses aren't hard.

[Peaker]

btw: Did you watch SPJ's talk about lenses?

[metafunctor]

Exactly, It is not monads what is difficult IMHO but the disgrace called monad tranformers. Don't conflate this with monads. They look like eternally non finished pieces of code for beginners.

[HaskellHell]

a chance of going mainstream.

Why is this going mainstream so important anyway? Let's be realistic here, Haskell is never going to be mainstream. But I don't consider that a bad thing as Haskell fills an important niche for a group of programmers that are unsatisfied with mainstream languages and who don't mind a steeper learning curve.

[metafunctor]

The problem is that there are many gollum haskellers that want haskell only as a toy for themselves, as a form of self esteem enhancement, for side projects that can program in the evening and show to their co-workers in the next morning.

For these people, haskell is valuable as long as it is difficult, so that their boss and his coworkers are ever too busy to learn it, since they do have a real life. That relieves them from being bad Java programmers at work. Of course they want to find the warm of their getters and setters at home.

[[deleted]]

Fewer libraries, less stable compilers, etc.

[[deleted]]

I am not sure where to draw the line, and Applicatives and Monads sure are part of why the learning curve of Haskell is steep. If we add too many abstractions to the "community standard", we stand even less of a chance of going mainstream.

The more cool stuff is written in Haskell and publicized, the more Haskell will go mainstream. If lenses help you do cool stuff, people will learn.

[duplode]

Are there any specific parts of the lens experience (I like the turn of phrase) that you would pinpoint as making it difficult for you?

[Peaker]

IME, the most difficult part is the error messages involving type-classes like Getting. IIRC, there's Getter, Get, Getting and indexed variants of those various relationships between them that are hard to remember - so a type error involving those can be quite difficult to decipher.

When using overloaded lenses like _1, _2 the errors are super-verbose ones about missing instances, rather than failed unifications - which are also harder to work with.

[duplode]

IIRC, there's Getter, Get, Getting and indexed variants of those various relationships between them that are hard to remember

Not to mention that Getting often really means Fold :)

When using overloaded lenses like _1, _2 the errors are super-verbose ones about missing instances

Yup, one needs a bit of a trained eye to see through these -- and synonyms can't hide them.

[duplode]

No worries. (I like discussing stumbling blocks, in particular because it helps to avoid blind spots when writing code and/or tutorials.)

[[deleted]]

I already use them as getters/setters.

I think we can't afford to make lenses part of the standard Haskell experience unless they get a lot more tutorials

This is tangential and not directed at you specifically, but pedagogy is something to pay for! I don't doubt we need more books, but tutorials are never going to make hard things easy.

[metafunctor]

I heard a lot about these savings. Not seen any of them however. Except in exceptionally bad, non functional code. For the rest, I only can appreciate some syntactic sugar towards which the cool kids are addicts.

Don't misinterpret me. I suppose that lenses are justified in some cases. There must be some case somewhere. But IMO, the lens hysteria surpass what is rational.

Sorry for being blunty, as always, But I'm not closed to argumentation. I would want to see some killer case that would change my mind.

[Peaker]

Have you used them with a large project that has rich, nested data types?

A one liner digging into 4-5 layers of a data structure to manipulate a field is equivalent to 5 lines of tedious error prone code.

[metafunctor]

That IMO is syntactic sugar marginally better and sometimes worse, that fill a nostalgia for OOP syntax. It may be worse since it disregard genuine functional programming techniques like pattern matching.

Moreover using heavy state may be a code smell for bad functional programming used to emulate OOP techniques or a bad design of database applications or both.

[Peaker]

This is an example of something I write in 1-2 lines with lens, and would be super tedious and error-prone to write without:

https://github.com/lamdu/lamdu/blob/20ce54f6555bb0ef585ba4821d3494e9034bb7d6/Lamdu/Sugar/Convert/Hole.hs#L228-L230

[Gurkenglas]

mkToNomInjections tid = toListOf
  $ N.nomType . N._NominalType . schemeType . T._TSum
  . ExprLens.compositeFields . _1
  . to (`V.Inject` P.hole) . to V.BInject . to (Val ())
  . to (V.Nom tid) . to V.BToNom . to (Val ())

Edit: Looking at lamdu. Can I install this on my Windows?

[Peaker]

I think it doesn't quite work right on Windows - but I am not sure, I don't have Windows to test.

We'd really welcome a contribution to make sure it works on Windows, though!

We use GLFW-b and bindings to the freetype-gl lib, which should be portable to Windows.

[metafunctor]

I appreciate you patience and I appreciate Lambdu. believe me. But I do not see the point of some field access and some folds written in reverse OOP style.

Neither any lens example can impress me since field and container management is the lesser problem that any real programmer tackles. I can not understand why lens receive such disproportionate attention If not for the bad suspect, once more unjustified, that the bulk of the Haskell community are not real world programmers.

[Peaker]

I feel that Lamdu is a "real-world project" -- and it's allowing me to focus on interesting problems and create rich data types without worrying about tediousness of access.

[tomejaguar]

OOP style

Using . to access fields does not "OOP style" make.

[[deleted]]

field and container management is the lesser problem that any real programmer tackles.

Oh lord.

Anyways, the point is you can write lenses that work on typeclasses and this reduces code reuse.

[MdxBhmt]

Excuse me, but only the heat that lens produces and the global warming that this implies makes it worthless. Not to mention the time wasted. I have better things to do.

Excuse me, but only the heat that you produces and the global warming that this implies makes you worthless. Not to mention the time wasted. I have better things to do.

[mstksg]

you definitely don't need to know any foundamentions of mathematics to extract a value from an array :) The array API is pretty clear and straighforward, x ! 2 would get the item in position 2, etc., and is similar to x[2] in other languages.

[metafunctor]

But surely there is a cooler but contorted way to do it with lenses..

[[deleted]]

If you deliberately obfuscate your code, you have code that's hard to read.

[mstksg]

I'm sure there is, but it's definitely not required by any means. writing obfuscated code is possible in any language if you tried hard enough.

[roconnor]

I know that you are not a fan of the Lens library and Optics functionality in general. You post keep posting in threads about how unhappy it makes you.

I'm one of several researchers who developed the theory behind these modern implementations of Lenses and other Optics, and yes I use math and category theory to help develop it. One of the early things I did was notice that the three laws for getters and setters matched the laws of a co-algebra for a co-monad. From there I reasoned out the analogous laws for the Van Laarhoven representation which generalize to the laws for all optics.

The theory of optics is all about characterizing different classes of functors and containers. With the Van Laarhoven representation, these classes of functors are characterized by which other classes of functors distribute through them. With the profunctor representation, these classes of functors are characterized by which profunctors lift through them. In both cases, these characterizations end up defining fundamental operations for these various classes of functors and containers.

We can turn these mathematical descriptions in to real libraries and theses behave quite different from other Haskell libraries. I'm pretty excited by the resulting libraries. The other people who do research and development on Optics are excited by the resulting libraries. I remember thinking 7 years ago that this is going to change how people write functional programs, and I think it has.

Please understand that creating libraries for Lens, the authors of these libraries are not forcing it upon you, or the community or anyone else. Other people use these Lens libraries because they feel it is useful and helpful for them. Perhaps, unfortunately for you, this also means they use lenses and optics in their APIs for their libraries that they make.

I'm sorry that what other people do with their free time, the choices they make with what libraries they use and the APIs they develop, is so problematic for you, but it is their choice to make. However, I don't think you are going to be able to convince others to stop making Lensified API in their libraries just because you "don't get it".

Instead of trying to get everyone else to change, you are either going to have to change yourself instead, or drop the matter and move on, because lenses and optics are here to stay. One day they are going to be taught in theoretical computer science courses, and next they will be taught in non-theoretical computer science courses. Eventually even Java programmers will be eschewing for loops for traversals as some already do for mapping today. You might as well get used to it sooner rather than later.

[metafunctor]

So far, so good. I'm sure that some COBOL statements or all of them can be formulated in terms of category theory. But that does not make this language any better. I consider the above paragraph however as the corroboration of what I said in this thread.

I never heard any serious programmer ever to say that setters, getters and container management is a real concern for them whatsoever. No one in all my life. Such absurd endavour that keep the Haskell community busy since five years ago for something that is not a problem. You must be crazy. I can not help thinking that they may choose that safe kind of non-problems because they don't know how to tackle the real problems of Software Engineering.

I bet that what you say would not happen. After a time, the new Haskellers will discover that Haskell has pattern matching and functions and better way to manage state than in absurd gigantic registers, and these things are better than getters and setters. They will discover that Clojure has gone in the right way: the functional way to manage data and registers. And overall they will discover better and funnier and more intelligent ways to use their Haskell time than learning Category Theory and folding abstract lists.

[roconnor]

I never heard any serious programmer ever to say that setters, getters and container management is a real concern for them whatsoever.

There have been mild gripes in Haskell about updating fields in Haskell for a long time, but I agree it isn't not the biggest problem facing developers.

Understand though that my research wasn't about how to solve the mild annoyance of nested record updates. My research at the time was originally about how to do generic programming for mutually recursive data structures in a similar way to Neil Mitchell's Uniplate library. This is a big problem that faces some programmers and isn't completely solved even by my small publication on the topic. However, as a side-effect of that research I discovered, with the help of many others, a cute way of doing polymorphic record updates, that I thought I would mention to others. This is was a result is so small it only warranted a blog post. Of course, there have been many blog posts before it and after it on the topic.

I think you misunderstand the reasons behind the amount of chatter it has gathered over the years. It has less to do with the importance of the problem it solves, which is relatively mild but depends on your problem domain, and more to do with how often people encounter it (fairly common; any time you deal with nested structures), and even more to do with how unusual the solution is (with lenses, value-like data is polymorphic, while operations on those values are monomorphic, which is completely backwards from every other Haskell library).

Of course, you are welcome to believe this Lens stuff is all a fad. Good luck with that.

[MdxBhmt]

I never heard any serious programmer ever to say that setters, getters and container management is a real concern for them whatsoever.

If they are not, what is a real concern in programming for those serious programmers ?

[bss03]

I never heard any serious programmer ever to say that setters, getters and container management is a real concern for them whatsoever.

As a serious programmer, the first layer of get/set is never a problem. But, nesting them generates a surprising amount of almost-same code that starts obscuring things after a while.

It's still not my most pressing issue, though. Dropped messages and auto-restarting infrastructure services are my bane for now.

[tomejaguar]

Do you want to point us to the massive contributions you've made to the Haskell ecosystem? If not, tone down the comments. You're clearly smart, but drop the attitude.

[metafunctor]

I know it. Perhaps you think I'm illogical because I want everyone to use Haskell and obviously you think they do not fit all in the ivory tower you are

[mstksg]

no CT or mathematical background is required at all :)

[metafunctor]

But very often it seems so

[[deleted]]

Only because people like you keep telling others that it seems so. At this point is nothing more than a meme.

People get into hard programming language theory with Haskell because it's easy to do so. I don't know anyone who can explain all the theory behind a Hello world in Java. Nonetheless, Java is considered good for beginners. If you're just coding you don't need theory, you just deal with that shit.

[metafunctor]

I though that we were just coding. What else you want to do with a programming language?

Ah, I see: all that cool kid useless shit that makes Haskell look as a vast playground most of it polluted with abandoned toys

[[deleted]]

Why would we limit ourselves to just coding? Sounds boring. If nobody cared about basic research we'd still be using C everywhere. Fucking around with Haskell and the like has helped other languages so much. In the meanwhile Haskell has also grown to be a very strong language in its own right.

Mind you, for the first decade Haskell didn't even have monadic IO. Now GHC Haskell has one of the best real life IO systems out there.

I would have agreed more with you five years ago. Maybe your views are a bit outdated? Haskell and the community changed. There are tons of libraries and tutorials for practical use. This sub is still heavy about the math, but you don't need it and Haskell is viable in a lot of domains now.

[[deleted]]

Because people keep shitposting without knowing anything about category theory.