3 ms·

Is this something like Lens in Haskell?

by js8 8y ago

thaumasiotes 8y ago
> If you have a Haskell background, I'm sure you're screaming to yourself "Lenses! Lenses!" I actually didn't know about lenses before I made Specter, but they are certainly very similar. I'm not on expert on Haskell, but what I do know is it explicitly distinguishes between navigators that go to one element (Lens) vs. zero or more (Traversal). I fail to see how that complication adds any sort of expressive or performance benefit, but perhaps a Haskeller out there can educate me.
- involans 8y ago
  It is useful to be able to speak of Lens and Traversal to distinguish intent. All lenses are Traversals, but not vice versa. What you have here is of course the Traversal system without the other optics.
  - Tarean 8y ago
    It's also useful for stuff like 'get' to look differently. user ^. id txt ^? _JSON . key "foo" txt ^?! _JSON . key "foo" First one gives exactly one result. The second one is the equivalent of returning null on failure. The third one throws an exception on failure. And because of the somewhat peculiar implementation of van laarhoven lenses we get subtyping so it doesn't get in the way.
- js8 8y ago
  I like Haskell more than Clojure, but I don't know much about lenses and traversals myself either. The reason I came to like Haskell is that they tend to ground things in (type/category) theory, which gives you extremely strong foundation (the downside is that sometimes things get so abstract that it's really tough to understand them). I don't disapprove the Clojure (and Lisp) approach of experimentation with new features, rather than trying to figure out the theory, but it can lead to unforeseen problems where you make design mistakes that are not obvious at the first sight. A good example is a recent discussion https://news.ycombinator.com/item?id=18565826 https://news.ycombinator.com/item?id=18565826 about Maybe. There are several good arguments in the thread against the union types, which are very easy to miss at first glance. So, I would recommend you dive into the theory of Lenses and Traversals, to see if you can avoid some mistakes you're perhaps doing (AFAIK there are several different definitions of lens in Haskell). As they say, a month in the lab can save you an afternoon in the library. Although I agree that lab is much more fun!
- dwohnitmok 8y ago
  Lenses are a kind of Traversal in the same way a square is a kind of rectangle. Everywhere you use a Traversal you can use a lens. A lens just happens to guarantee you can always get the element you're looking for and so more restrictive functions that cannot tolerate failure to find an element must use lenses. The more fundamental divide is between lenses and prisms (which are also a kind of Traversal).
- thom 8y ago
  Good opportunity to post this: http://hackage.haskell.org/package/lens-4.17/docs/Control-Lens-Operators.html http://hackage.haskell.org/package/lens-4.17/docs/Control-Le... Which I still maintain is the most hilarious API I have ever seen in my life.

Is this something like Lens in Haskell?

by js8 8y ago

Is this something like Lens in Haskell?

> If you have a Haskell background, I'm sure you're screaming to yourself "Lenses! Lenses!" I actually didn't know about lenses before I made Specter, but they are certainly very similar. I'm not on expert on Haskell, but what I do know is it explicitly distinguishes between navigators that go to one element (Lens) vs. zero or more (Traversal). I fail to see how that complication adds any sort of expressive or performance benefit, but perhaps a Haskeller out there can educate me.

involans 8y ago
It is useful to be able to speak of Lens and Traversal to distinguish intent. All lenses are Traversals, but not vice versa. What you have here is of course the Traversal system without the other optics.
- Tarean 8y ago
  It's also useful for stuff like 'get' to look differently. user ^. id txt ^? _JSON . key "foo" txt ^?! _JSON . key "foo" First one gives exactly one result. The second one is the equivalent of returning null on failure. The third one throws an exception on failure. And because of the somewhat peculiar implementation of van laarhoven lenses we get subtyping so it doesn't get in the way.
js8 8y ago
I like Haskell more than Clojure, but I don't know much about lenses and traversals myself either. The reason I came to like Haskell is that they tend to ground things in (type/category) theory, which gives you extremely strong foundation (the downside is that sometimes things get so abstract that it's really tough to understand them). I don't disapprove the Clojure (and Lisp) approach of experimentation with new features, rather than trying to figure out the theory, but it can lead to unforeseen problems where you make design mistakes that are not obvious at the first sight. A good example is a recent discussion https://news.ycombinator.com/item?id=18565826 https://news.ycombinator.com/item?id=18565826 about Maybe. There are several good arguments in the thread against the union types, which are very easy to miss at first glance. So, I would recommend you dive into the theory of Lenses and Traversals, to see if you can avoid some mistakes you're perhaps doing (AFAIK there are several different definitions of lens in Haskell). As they say, a month in the lab can save you an afternoon in the library. Although I agree that lab is much more fun!
dwohnitmok 8y ago
Lenses are a kind of Traversal in the same way a square is a kind of rectangle. Everywhere you use a Traversal you can use a lens. A lens just happens to guarantee you can always get the element you're looking for and so more restrictive functions that cannot tolerate failure to find an element must use lenses. The more fundamental divide is between lenses and prisms (which are also a kind of Traversal).
thom 8y ago
Good opportunity to post this: http://hackage.haskell.org/package/lens-4.17/docs/Control-Lens-Operators.html http://hackage.haskell.org/package/lens-4.17/docs/Control-Le... Which I still maintain is the most hilarious API I have ever seen in my life.