KLklntsky·Dec 6, 2022
They are in fact well structured and not random at all. Take a look at this:
https://github.com/ekmett/lens/wiki/Operators
In Exercises for understanding Haskell Lenses (2019)ekmett
lens
Haskell2012–2022
ekmett / lens
lens
Lenses, Folds, and Traversals - Join us on web.libera.chat #haskell-lens
13Distinct people
13Mentions
0Explicit recommenders
2.1KGitHub stars
What to know before exploring
What it is
Lenses, Folds, and Traversals - Join us on web.libera.chat #haskell-lens
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year13 dated mentions
Observed mentions: 2012-10-31 16:57:58 UTC to 2022-12-06 14:05:45 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
13 sourcesThe documentation of lenses is geared towards people know what lenses are. Of course this single fragment of documentation doesn't make sense if you don't know what lenses are. If you want to understand what lenses are the package links to a helpful wiki and tutorial: https://github.com/ekmett/lens/wiki/Overview
All within reach within seconds of discovering the function. To understand any tool you must understand the libraries and tools it to some degree. Your questions here are not Haskell specific, and the answers to the question you asked are easy to find. I'm not familiar with the Dhall code base and was able to answer you within minutes.
In Dhall: A Gateway Drug to HaskellSo that's where the lens notation comes from...
https://github.com/ekmett/lens/wiki/Examples
> ("hello","world")^._2
In What is your favorite C programming trick? (2009)I don't understand what any of what you said has to do with established copyright law, and are you saying that IFTTT or Zapier are not copyrighted because they're "merely an interface" (what Java does for declaration code is as complex as what they do)? What about Haskell's mtl or lens that do even less? They seem to think they're copyrighted: https://github.com/ekmett/lens/blob/master/LICENSE
Oracle sued over the act of copying of 11K lines of extremely creative code for commercial purposes and not for compatibility. Nothing of this kind and magnitude has happened in the software industry. Any claim that this is about "copyrighting APIs" in general or changing anything about copyright and fair-use are biased interpretations.
In Oracle's history highlights a possible downside to its stance on API copyrightsA lot of the ideas used in everyday Haskell originated in category theory (similarly to how all our programming languages eventually come from Turing machines, the lambda calculus, and so on), but command over the mathematical ideas is absolutely not required to "get into Haskell" or even to use it productively and fluently. It is certainly something you should look into if you want to
a) know why some things are done the way they are (in case you're not satisfied with "this works!"), or
b) if you want to find inspiration to write a certain kind of library: Haskell is one of the few languages that has, as I like to call it, "over 50 years of documentation".
--
To elaborate: a category is a bunch of objects, and functions (morphisms) between the objects. The types in a language like Haskell form a category (called Hask in this case) where
Read the rest
the objects are the types and morphisms from one type to another are the functions that go from the former to the latter.
A lot of things done in Haskell are instances of general constructions from category theory applied to Hask. Comfort with these general constructions certainly helps to illuminate many ideas.
For example, the great trifecta of Haskell abstractions comprises three interfaces ("typeclasses") called Functor, Applicative, and Monad, which are used everywhere. Each of these corresponds to a concept from category theory: for instance, what a Haskeller calls a "Functor" is what is categorically called an "endofunctor on Hask". Among users of the language who know any category theory at all, most have some familiarity with things at the level of what I've just said, but not much more. A knowledge of category theory at any higher level (like in the linked repo) is not at all common, statistically.
Also, not many of the common libraries are based on deep categorical ideas (lens [0] is an important exception) but even then, knowledge of the mathematics is useful if you want to dig into how the ideas are implemented, not if you're happy just using them. Learn as little or as much as you'd like.
[0] https://github.com/ekmett/lens/wiki/Examples
Two links that come to mind:
- https://github.com/ocharles/netwire-classics
- https://github.com/ekmett/lens/blob/master/examples/Pong.hs
In Purely Functional Retrogames (2008)A select few operators (out of hundreds) for a single Haskell library: https://github.com/ekmett/lens/wiki/Operators
(For full disclosure, the lens library is infamous for this.)
In What do you call this in Ruby?The author seems to be getting at something very similar to the notion of "bidirectional programming" [1][2]. It's a concept that's closely related to the indispensable "lens" library in Haskell [3].
[1] http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides...
[2] http://www.janis-voigtlaender.eu/papers/ThreeComplementaryAp...
[3] https://github.com/ekmett/lens
In In J, functions have inverses (2012)Hmmm, perhaps my cursory skim of Wikipedia and the Ceylon site led me to wrong conclusions there. I'll defer a more detailed type system comparison to experts in the field. The big difference I see on my second pass is purity. Purity in Haskell is huge IMO. I would argue that purity makes Haskell's type system more powerful because a function's type allows you to know exactly what kinds of side effects it might have, or more importantly, not have. But I suppose one could debate whether that's a type system thing or not.
> can be a bit cumbersome to do imperative and side-effect programming
On the contrary, I think Haskell is great for imperative programming. It allows you to operate at higher levels of abstraction and create more abstract imperative constructs than most other languages. If you want to mutate things, there is a smal
Read the rest
l cost to construct IORefs, STRefs, and the like, but I think that's actually a good thing because it correctly incentivizes the reduction of side effects. And again, much of this boilerplate can be gotten rid of. See https://github.com/ekmett/lens/blob/master/examples/Pong.hs#... for an example of some really nice imperative code made possible by the lens library.
Haskell's Lens package (linked to above) is indeed nice. For a practical quickstart guide, I'de recommend the Github page over the Hackage page:
https://github.com/ekmett/lens#lens-lenses-folds-and-travers...
In Fat JSONI will write this answer in the flavor of your average Haskell library, as read by somebody who has learned the core language very well but not that library:
you <*$%^> everyone %%<#>%% experience
Are you really going to tell me you have never looked at code written with a package you haven't learned and initially found it to be unintelligible? If not, then I would guess that you are simply well-suited to Haskell. Again, I'm not saying Haskell is bad, but that it does have attributes that make it daunting to many people. The top-rated comment on here even talks about how easy Haskell is now that he's "over the hump." Even compared to a relatively esoteric language like Clojure, Haskell's hump is pretty big.
I believe the canonical example of a weird math-based library that makes beginners cry is Control.Arrow. Reading arrow-based code
Read the rest
without having fully grasped both the idea of arrows and the API itself (do you think <&&&> could use a few more ampersands?) is an exercise in frustration. Even the humble monoid — simple as it may be — is hard for many people to grasp, because they're such a frustratingly generic idea with horribly unhelpful terminology attached to them.
Want more? Here's one of the top Haskell projects on Github — a library that does lenses, folds, traversals, getters and setters: https://github.com/ekmett/lens
With that library, you can write things like
_1 .~ "hello" $ ((),"world")
Indeed, it's not the whole story. Infinite types and recursive types will come along in part 2!
As to the practical advantage - does there have to be one? Isn't the fact that it's intellectually gratifying enough?
If you insist, though - I sometimes see the kind of laws I presented used in actual Haskell code. For example, in the Data.Lens package[0] you can consider a lens on a a structure of type a to be composed of a getter and a setter of values of type b
data Lens a b = Lens (a -> b, a -> b -> a)
which is refactored, using the law (a -> b, a -> c) == a -> (b,c), to look like
data Lens a b = Lens (a -> (b, b -> a))
which allows for a more efficient 'modify' operation. It also allows you to notice that lenses are related to the 'Store' comonad[1]:
data Store b a = Store (b, b -> a)
data Lens a b = Lens (a -> Store b a
Read the rest
)
on which a lot of the Data.Lens internals are based.
[0] https://github.com/ekmett/lens
[1] http://stackoverflow.com/questions/8766246/what-is-the-store...
The state of the art is the amazing `lens` package https://github.com/ekmett/lens/wiki/Overview . See this example, https://github.com/ekmett/lens/blob/master/examples/Pong.hs
In Haskell in Production: The good, the bad, and the ugly