however: why those instead of iterators or functions? how is a `lens` not a function in general (or a yielding iterator) which return some kind of views?
A lens is a (1) functional (2) bi-directional (3) first-class and (4) composable generalization of (5) struct field names in most traditional languages.
1) "Functional" meaning we eschew mutation and implicit context. Mutation is a very powerful feature of a language, and much can be encoded using it. When we remove mutation as an option, many of the things we would have just used mutation for separate into distinct and rich solution spaces.
2) "Bi-directional" meaning we can use the same widget for both accessing a sub-part of a whole, and for replacing that sub-part within a whole. I personally call these operations "extract" and "replace", since "get" and "set" feel like they raise the specter of mutability.
3) "First-class" means that the lenses themselves are manipulable constructs within the language. In a language like C or Java, I can have "obj.a.b.c", but I cannot have ".a.b.c" itself on its own. Even if you consider method references (like "Obj::a" in Java), you've only obtained the ability to extract the "a" field from an Obj -- any particular method or function is only going to go in one direction.
4) "Composable" means that you can take two lenses and fit them together to get a new lens. Conceptually, I think this is understood -- we intuitively understand how to navigate an object graph when writing down an expression like "obj.a.b.c" -- but having a composable first-class abstraction lets us do the same thing programmatically. (It need not even be at "runtime" -- imagine a compile-time macro system that programmatically generates nested accesses from some base rules you define. I think you've got the rudiments of a dependency injection system here.)
5) "Struct field" means that for the given type, the field is always accessible. "List element" (or "tree leaf", ...) would give you traversals instead of lenses, and "tagged union variant" / "subclass" would give you prisms.
As for potential applications of the approach, there's the approach dependency injection graphs outlined above. I've also used ideas from lenses/prisms in serialization/deserialization and web service middleware. (Middleware compose really well as functional optics!)
With profunctor optics, you can even construct self-describing operations. For instance, imagine a JSON parser that can be directly interrogated to obtain the schema it accepts, or a middleware stack that can be interrogated to determine which headers it looks at, and which routes it accepts. Personally, this is the area I'm most excited about with functional optics.
> With profunctor optics, you can even construct self-describing operations. For instance, imagine a JSON parser that can be directly interrogated to obtain the schema it accepts, or a middleware stack that can be interrogated to determine which headers it looks at, and which routes it accepts. Personally, this is the area I'm most excited about with functional optics.
I’m not sure this has anything to do with profunctor optics per se; you can do it with any structure which is polymorphic enough. (A neat example I saw recently: Build Systems à la Carte [0] allow you to get a list of dependencies from a build task, as long as that task is Applicative i.e. does not have dynamic dependencies.)
[0] https://www.microsoft.com/en-us/research/uploads/prod/2018/0...
Thank you!
> I'm not sure this has anything to do with profunctor optics per se
Yes, fair! I didn't mean to imply that only profunctor constructions can be self-descriptive. Rather, I meant that optics based solely on the function arrow don't really give you anywhere to annotate with description in the first place. By assuming less about the operations they're lifting, profunctor optics give you more freedom to model a self-descriptive profunctorial operation.
In the `(a -> f b) -> (s -> f t)` formulation, the lens takes a function and returns an adapted function. There's nowhere to put additional information, and even if you could stash it on the `f`, you'd have to feed it an `s` just to get at it.
In the `p a b -> p s t` formulation, the function arrow (if it's used in your chosen `p` at all!) doesn't have to be the top-level type you return; you could have something like `(a -> f b, Metadata)` instead. You can add combinators to your concrete `p` that manage the metadata and let you combine multiple such operations, and intermix them freely with profunctor-generic lenses that don't care what concrete profunctor you're using. In the end, you get a `p a b` with the metadata immediately available and not necessarily hidden under a function application.
This distinction only comes up because lenses are polymorphic in both the input and output types. The example of a JSON parser is only polymorphic in its output type (we can assume the input is always some String), so you can easily get a `Parser b` with all the metadata at the surface. Since Profunctors have two type parameters, one covariant and one contravariant, we can build models that vary over the input type while retaining the ability to be self-descriptive.
I read a blog post recently [0] that showed some examples of using Profunctors in this way. It also shows the relationship between Profunctor and Arrow; the latter is basically a Strong Profunctor (you can turn a `p a b` into a `p (c, a) (c, b)` that threads a `c` through unaltered) where you can also compose Profunctor elements directly (`p a b -> p b c -> p a c`). In the end, you get an entire operation `p a z` in your Profunctor, with any statically observable metadata ready to be extracted from its structure.
[0] https://elvishjerricco.github.io/2017/03/10/profunctors-arro...