Our previous posts on computational pipelines, such as those introducing Funflow and Porcupine, show that Arrows are very useful for data science workflows.
They allow the construction of effectful and composable pipelines whose structure is known at compile time, which is not possible when using Monad
s.
However, Arrows may seem awkward to work with at first. For instance,
it’s not obvious how to use lenses to access record fields in Arrows.
My goal in this post is to show how lenses and other optics can be used in Arrowbased workflows. Doing so is greatly simplified thanks to Profunctor optics and some utilities that I helped add to the latest version of the lens library.
Optics on functions
We’re used to think of lenses in terms of getters and setters, but I’m
more interested today in the functions over
and traverseOf
.
 We will use this prefix for the remaining of the post.
 VL stands for Van Laarhoven lenses.
import qualified Control.Lens as VL
 Transform a pure function.
over :: VL.Lens s t a b > (a > b) > (s > t)
 Transform an effectful function.
traverseOf :: VL.Traversal s t a b > (a > m b) > (s > m t)
We would like to use similar functions on Arrowbased workflows, something like
overArrow :: VL.Lens s t a b > Task a b > Task s t
However, the type of lenses:
type Lens s t a b = forall f. Functor f => (a > f b) > s > f t
doesn’t make it very obvious how to define overArrow
.
On the other hand, Arrows come equipped with functions first
and second
:
first :: Task b c > Task (b, d) (c, d)
second :: Task b c > Task (d, b) (d, c)
which very much feel like specialised versions of overArrow
for the
lenses
_1 :: VL.Lens (b, d) (c, d) b c
_2 :: VL.Lens (d, b) (d, c) b c
so maybe there is a common framework that can take both of these into account? The answer is yes, and the solution is lenses — but lenses of a different type.
Profunctor optics
There is an alternative and equivalent formulation of optics, called Profunctor optics, that works very well with Arrows
.
Optics in the Profunctor
framework have the following shape:
type Optic p s t a b = p a b > p s t
with more precise optics such as Lens
being obtained by imposing constraints to p
coming from the different Profunctor classes.
In other words, an Optic
is precisely a higherorder function acting on some profunctor.
Because every Arrow is also a Profunctor^{1}, the shape
of an Optic
is precisely what is needed to act on Arrows! Moreover, like the optics of the lens
library, profunctor optics can be composed like regular functions, with (.)
.
The lens
library now includes a module containing functions that convert between standard and profunctor optics, which makes using them very convenient.
In the following sections, we will go through the use and the intuition of the most common optics: Lens
, Prism
and Traversal
.
But first, let’s import the compatibility module for profunctor optics:
 PL for Profunctor Lenses
import Control.Lens.Profunctor as PL
Lenses
Standard lenses are all about products — view
, for example, is used to deconstruct records:
view _fst :: (a, b) > a
Therefore, it makes sense for Profunctor lenses to also talk about products.
Indeed, that is exactly what happens, through the Strong
type class:
class Profunctor p => Strong p where
first' :: p a b > p (a, c) (b, c)
second' :: p a b > p (c, a) (c, b)
With profunctor optics, a Lens
is defined as follows:
type Lens s t a b = forall p. Strong p => p a b > p s t
Every Arrow
satisfies the Strong
class.
If we squint, we can rewrite the type of these functions as:
first' :: Lens' (a,c) (b,c) a b
second' :: Lens' (c,a) (c,b) a b
That is, a Strong
profunctor is equipped with lenses to reach
inside products.
One can always convert a record into nested pairs and act on them using Strong
— the Lens
just makes this much more convenient.
But how do we build a Lens
?
Besides writing them manually, we can also use all Lens
es from lens
:
PL.fromLens :: VL.Lens s t a b > Lens s t a b
which means we can still use all the lenses we know and love. For example, one can apply a task to a tuple of arbitrary size:
PL.fromLens _1 :: Task a b > Task (a,x,y) (b,x,y)
Summarizing, a Strong
profunctor is one we can apply lenses to.
Since every Arrow
is also a Strong
profunctor, one can use Lens
es with them.
Prisms
Standard prisms are all about sums — preview
, for example, is used to deconstruct sumtypes:
view _Left :: Either a b > Maybe a
Therefore, it makes sense for Profunctor prisms to also talk about sums.
Indeed, that is exactly what happens, through the Choice
type class:
class Profunctor p => Choice p where
left' :: p a b > p (Either a c) (Either b c)
right' :: p a b > p (Either c a) (Either c b)
With profunctor optics, a Prism
is defined as follows:
type Prism s t a b = forall p. Choice p => p a b > p s t
Every ArrowChoice
satisfies the Choice
class.
Once more, we can rewrite the type of these functions as:
left' :: Prism (Either a c) (Either b c) a b
right' :: Prism (Either c a) (Either c b) a b
That is, a Choice
profunctor is equipped with prisms to discriminate sums.
One can always convert a sum into nested Either
s and act on them using Choice
— the Prism
just makes this much more convenient.
But how do we build a Prism
?
We can also use any prisms from lens
with a simple conversion:
PL.fromPrism :: VL.Prism s t a b > Prism s t a b
For example, one can execute a task conditionally, depending on the existence of the input:
PL.fromPrism _Just :: Action a b > Action (Maybe a) (Maybe b)
Summarizing, a Choice
profunctor is one we can apply prisms to.
Since every ArrowChoice
can be a Choice
profunctor, one can uses prisms with them.
Traversals
Standard traversals are all about Traversable
structures — mapMOf
, for example, is used to execute effectful functions:
mapMOf traverse readFile :: [FilePath] > IO [String]
Therefore, it makes sense for Profunctor traversals to also talk about these traversable structures.
Indeed, that is exactly what happens, through the Traversing
type class:
class (Choice p, Strong p) => Traversing p where
traverse' :: Traversable f => p a b > p (f a) (f b)
With profunctor optics, a Traversal
is defined as follows:
type Traversal s t a b = forall p. Traversing p => p a b > p s t
There is no associated Arrow
class that corresponds to this class, but many Arrow
s, such as Kleisli
, satisfy it.
We can rewrite the type of this functions as:
traverse' :: Traversable f => Traversal (f a) (f b) a b
That is, a Traversing
profunctor can be lifted through Traversable
functors.
But how do we build a Traversal
?
We can also use any Traversal
from lens
with a simple conversion:
PL.fromTraversal :: VL.Traversal s t a b > Traversal s t a b
For example, one can have a task and apply it to a list of inputs:
PL.fromTraversal traverse :: Action a b > Action [a] [b]
Conclusion
Using Arrows does not stop us from taking advantage of the Haskell ecosystem.
In particular, optics interact very naturally with Arrows, both in their classical and profunctor formulations.
For the moment, the ecosystem is still lacking a standard library for Profunctor optics, but this is not a show stopper — the lens
library itself has most of the tools we need.
So the next time you are trying out Funflow or Porcupine, don’t shy away from using lens
!

The fact that these hierarchies are separated is due to historical reasons.
↩