# Haskell/Lenses and functional references

* Lenses and functional references (Solutions)
* Advanced Haskell
* Monoids
* Applicative functors
* Foldable
* Traversable
* Arrow tutorial
* Understanding arrows
* Continuation passing style
* Zippers
* Lenses
* Comonads
* Value recursion (MonadFix)
* Effectful streaming
* Mutable objects
* Concurrency
* Template Haskell
* Type Families
This chapter is about functional references. By "references", we mean they point at parts of values, allowing us to access and modify them. By "functional", we mean they do so in a way that provides the flexibility and composability we came to expect from functions. We will study functional references as implemented by the powerful lens library. lens is named after lenses, a particularly well known kind of functional reference. Beyond being very interesting from a conceptual point of view, lenses and other functional references allow for several convenient and increasingly common idioms, put into use by a number of useful libraries.

## A taste of lenses

As a warm-up, we will demonstrate the simplest use case for lenses: as a nicer alternative to the vanilla Haskell records. There will be little in the way of explanations in this section; we will fill in the gaps through the remainder of the chapter.
Consider the following types, which are not unlike something you might find in a 2D drawing library:
Record syntax gives us functions for accessing the fields. With them, getting the coordinates of the points that define a segment is easy enough:
Updates, however, are clunkier...
... and get downright ugly when we need to reach a nested field. Here is what it takes to double the value of the y coordinate of the end point:
Lenses allow us to avoid such nastiness, so let's start over with them:
The only real change here is the use of makeLenses, which automatically generates lenses for the fields of Point and Segment (the extra underscores are required by the naming conventions of makeLenses). As we will see, writing lenses definitions by hand is not difficult at all; however, it can be tedious if there are lots of fields to make lenses for, and thus automatic generation is very convenient.
Thanks to makeLenses, we now have a lens for each field. Their names match that of the fields, except with the leading underscore removed:
The type positionY :: Lens' Point Double tells us that positionY is a reference to a Double within a Point. To work with such references, we use the combinators provided by the lens library. One of them is view, which gives us the value pointed at by a lens, just like a record accessor:
Another one is set, which overwrites the value pointed at:
One of the great things about lenses is that they are easy to compose:
Note that when writing composed lenses, such as segmentEnd . positionY, the order is from large to small. In this case, the lens that focuses on a point of the segment comes before the one that focuses on a coordinate of that point. While that might look a little surprising in contrast to how record accessors work (compare with the equivalent lens-less example at the beginning of this section), the (.) used here is just the function composition operator we know and love.
Composition of lenses provide a way out of the nested record update quagmire. Here is a translation of the coordinate-doubling example using over, through which we can apply a function to the value pointed at by a lens:
These initial examples might look a bit magical at first. What makes it possible to use one and the same lens to get, set and modify a value? How come composing lenses with (.) just works? Is it really so easy to write lenses without the help of makeLenses? We will answer such questions by going behind the curtains to find what lenses are made of.

## The scenic route to lenses

There are many ways to make sense of lenses. We will follow a sinuous yet gentle path, one which avoids conceptual leaps. Along the way, we will introduce a few different kinds of functional references. Following lens terminology, from now on we will use the word "optics" to refer collectively to the various species of functional references. As we will see, the optics in lens are interrelated, forming a hierarchy. It is this hierarchy which we are now going to explore.

### Traversals

We will begin not with lenses, but with a closely related optic: traversals. The Traversable chapter discussed how traverse makes it possible to walk across a structure while producing an overall effect:
With traverse, you can use any Applicative you like to produce the effect. In particular, we have seen how fmap can be obtained from traverse simply by picking Identity as the applicative functor, and that the same goes for foldMap and Const m, using Monoid m => Applicative (Const m):
lens takes this idea and lets it blossom.
Manipulating values within a Traversable structure, as traverse allows us to, is an example of targeting parts of a whole. As flexible as it is, however, traverse only handles a rather limited range of targets. For one, we might want to walk across structures that are not Traversable functors. Here is an entirely reasonable function that does so with our Point type:
pointCoordinates is a traversal of Point. It looks a lot like a typical implementation of traverse, and can be used in pretty much the same way. The only difference is that Point has a fixed type inside (Double) instead of being a polymorphic type. Here is an adaptation of the rejectWithNegatives example from the Traversable chapter:
This generalised notion of a traversal that pointCoordinates exemplifies is captured by one of the core types of lens: Traversal.
Note
The forall f. on the right side of the type declaration means that any Applicative can be used to replace f. That makes it unnecessary to mention f on the left side, or to specify which f to pick when using a Traversal.
With the Traversal synonym, the type of pointCoordinates can be expressed as:
Let's have a closer look at what became of each type variable in Traversal s t a b:
* s becomes Point: pointCoordinates is a traversal of a Point.
* t becomes Point: pointCoordinates produces a Point (in some Applicative context).
* a becomes Double: pointCoordinates targets Double values in a Point (the X and Y coordinates of the points).
* b becomes Double: the targeted Double values become Double values (possibly different than the original ones).
In the case of pointCoordinates, s is the same as t, and a is the same as b. pointCoordinates does not change the type of the traversed structure, or that of the targets in it, but that need not be the case. One example is good old traverse, whose type can be expressed as:
traverse is able to change the types of the targeted values in the Traversable structure and, by extension, the type of the structure itself.
The Control.Lens.Traversal module includes generalisations of Data.Traversable functions and various other tools for working with traversals.
* Exercises
* Write extremityCoordinates, a traversal that goes through all coordinates of the points that define a Segment in the order suggested by the data declaration. (Hint: use the pointCoordinates traversal.)

### Setters

Next in our programme comes the generalisation of the links between Traversable, Functor and Foldable. We shall begin with Functor.
To recover fmap from traverse, we picked Identity as the applicative functor. That choice allowed us to modify the targeted values without producing any extra effects. We can reach similar results by picking the definition of a Traversal...
... and specialising f to Identity:
In lens parlance, that is how you get a Setter. For technical reasons, the definition of Setter in Control.Lens.Setter is a little different...
... but if you dig into the documentation you will find that a Settable functor is either Identity or something very much like it, so the difference need not concern us.
When we take Traversal and restrict the choice of f we actually make the type more general. Given that a Traversal works with any Applicative functor, it will also work with Identity, and therefore any Traversal is a Setter and can be used as one. The reverse, however, is not true: not all setters are traversals.
over is the essential combinator for setters. It works a lot like fmap, except that you pass a setter as its first argument in order to specify which parts of the structure you want to target:
In fact, there is a Setter called mapped that allows us to recover fmap:
Another very important combinator is set, which replaces all targeted values with a constant. set setter x = over setter (const x), analogously to how (x <$) = fmap (const x):
* Exercises
* Use over to implement... scaleSegment :: Double -> Segment -> Segment... so that scaleSegment n multiplies all coordinates of a segment by x. (Hint: use your answer to the previous exercise.)
* Implement mapped. For this exercise, you can specialise the Settable functor to Identity. (Hint: you will need Data.Functor.Identity.)

### Folds

Having generalised the fmap-as-traversal trick, it is time to do the same with the foldMap-as-traversal one. We will use Const to go from...
... to:
Since the second parameter of Const is irrelevant, we replace b with a and t with s to make our life easier.
Just like we have seen for Setter and Identity, Control.Lens.Fold uses something slightly more general than Monoid r => Const r:
Note
Contravariant is a type class for contravariant functors. The key Contravariant method is contramap...
... which looks a lot like fmap, except that it, so to say, turns the function arrow around on mapping. Types parametrised over function arguments are typical examples of Contravariant. For instance, Data.Functor.Contravariant defines a Predicate type for boolean tests on values of type a:
Predicate is a Contravariant, and so you can use contramap to modify a Predicate so that the values are adjusted in some way before being submitted to the test:
Contravariant has laws which are analogous to the Functor ones:
Monoid r => Const r is both a Contravariant and an Applicative. Thanks to the functor and contravariant laws, anything that is both a Contravariant and a Functor is, just like Const r, a vacuous functor, with both fmap and contramap doing nothing. The additional Applicative constraint corresponds to the Monoid r; it allows us to actually perform the fold by combining the Const-like contexts created from the targets.
Every Traversal can be used as a Fold, given that a Traversal must work with any Applicative, including those that are also Contravariant. The situation parallels exactly what we have seen for Traversal and Setter.
Control.Lens.Fold offers analogues to everything in Data.Foldable. Two commonly seen combinators from that module are toListOf, which produces a list of the Fold targets...
... and preview, which extracts the first target of a Fold using the First monoid from Data.Monoid.

### Getters

So far we have moved from Traversal to more general optics (Setter and Fold) by restricting the functors available for traversing. We can also go in the opposite direction, that is, making more specific optics by broadening the range of functors they have to deal with. For instance, if we take Fold...
... and relax the Applicative constraint to merely Functor, we obtain Getter:
As f still has to be both Contravariant and Functor, it remains being a Const-like vacuous functor. Without the Applicative constraint, however, we can't combine results from multiple targets. The upshot is that a Getter always has exactly one target, unlike a Fold (or, for that matter, a Setter, or a Traversal) which can have any number of targets, including zero.
The essence of Getter can be brought to light by specialising f to the obvious choice, Const r:
Since a Const r whatever value can be losslessly converted to a r value and back, the type above is equivalent to:
An (a -> r) -> s -> r function, however, is just an s -> a function in disguise (the camouflage being continuation passing style):
Thus we conclude that a Getter s a is equivalent to a s -> a function. From this point of view, it is only natural that it takes exactly one target to exactly one result. It is not surprising either that two basic combinators from Control.Lens.Getter are to, which makes a Getter out of an arbitrary function, and view, which converts a Getter back to an arbitrary function.
Note
Given what we have just said about Getter being less general than Fold, it may come as a surprise that view can work Folds and Traversals as well as with Getters:
That is possible thanks to one of the many subtleties of the type signatures of lens. The first argument of view is not exactly a Getter, but a Getting:
Getting specialises the functor parameter to Const r, the obvious choice for Getter, but leaves it open whether there will be an Applicative instance for it (i.e. whether r will be a Monoid). Using view as an example, as long as a is a Monoid Getting a s a can be used as a Fold, and so Folds can be used with view as long as the fold targets are monoidal.
Many combinators in both Control.Lens.Getter and Control.Lens.Fold are defined in terms of Getting rather than Getter or Fold. One advantage of using Getting is that the resulting type signatures tell us more about the folds that might be performed. For instance, consider hasn't from Control.Lens.Fold:
It is a generalised test for emptiness:
Fold s a -> s -> Bool would work just as well as a signature for hasn't. However, the Getting All in the actual signature is quite informative, in that it strongly suggests what hasn't does: it converts all a targets in s to the All monoid (more precisely, to All False), folds them and extracts a Bool from the overall All result.

### Lenses at last

If we go back to Traversal...
... and relax the Applicative constraint to Functor, just as we did when going from Fold to Getter...
... we finally reach the Lens type.
What changes when moving from Traversal to Lens? As before, relaxing the Applicative constraint costs us the ability to traverse multiple targets. Unlike a Traversal, a Lens always focuses on a single target. As usual in such cases, there is a bright side to the restriction: with a Lens, we can be sure that exactly one target will be found, while with a Traversal we might end up with many, or none at all.
The absence of the Applicative constraint and the uniqueness of targets point towards another key fact about lenses: they can be used as getters. Contravariant plus Functor is a strictly more specific constraint than just Functor, and so Getter is strictly more general than Lens. As every Lens is also a Traversal and therefore a Setter, we conclude that lenses can be used as both getters and setters. That explains why lenses can replace record labels.
Note
On close reading, our claim that every Lens can be used as a Getter might seem rash. Placing the types side by side...
... shows that going from Lens s t a b to Getter s a involves making s equal to t and a equal to b. How can we be sure that is possible for any lens? An analogous issue might be raised about the relationship between Traversal and Fold. For the moment, this question will be left suspended; we will return to it in the section about optic laws.
Here is a quick demonstration of the flexibility of lenses using _1, a lens that focuses on the first component of a tuple:
* Exercises
* Implement the lenses for the fields of Point and Segment, that is, the ones we generated with makeLenses early on. (Hint: Follow the types. Once you write the signatures down you will notice that beyond fmap and the record labels there is not much else you can use to write them.)
* Implement the lens function, which takes a getter function s -> a and a setter function s -> b -> t and produces a Lens s t a b. (Hint: Your implementation will be able to minimise the repetitiveness in the solution of the previous exercise.)

## Composition

The optics we have seen so far fit the shape...
... in which:
* f is a Functor of some sort;
* s is the type of the whole, that is, the full structure the optic works with;
* t is the type of what the whole becomes through the optic;
* a is the type of the parts, that is, the targets within s that the optic focuses on; and
* b is the type of what the parts becomes through the optic.
One key thing those optics have in common is that they are all functions. More specifically, they are mapping functions that turn a function acting on a part (a -> f b) into a function acting on the whole (s -> f t). Being functions, they can be composed in the usual manner. Let's have a second look at the lens composition example from the introduction:
An optic modifies the function it receives as argument to make it act on a larger structure. Given that (.) composes functions from right to left, we find that, when reading code from left to right, the components of an optic assembled with (.) focus on progressively smaller parts of the original structure. The conventions used by the lens type synonyms match this large-to-small order, with s and t coming before a and b. The table below illustrates how we can look at what an optic does either a mapping (from small to large) or as a focusing (from large to small), using segmentEnd . positionY as an example:
| Lens | segmentEnd | positionY | segmentEnd . positionY |
| Bare type | Functor f => (Point -> f Point) -> (Segment -> f Segment) | Functor f => (Double -> f Double) -> (Point -> f Point) | Functor f => (Double -> f Double) -> (Segment -> f Segment) |
| "Mapping" interpretation | From a function on Point to a function on Segment. | From a function on Double to a function on Point. | From a function on Double to a function on Segment. |
| Type with Lens | Lens Segment Segment Point Point | Lens Point Point Double Double | Lens Segment Segment Double Double |
| Type with Lens' | Lens' Segment Point | Lens' Point Double | Lens' Segment Double |
| "Focusing" interpretation | Focuses on a Point within a Segment | Focuses on a Double within a Point | Focuses on a Double within a Segment |
Note
The Lens' synonym is just convenient shorthand for lenses that do not change types (that is, lenses with s equal to t and a equal to b).
There are analogous Traversal' and Setter' synonyms as well.
The types behind synonyms such as Lens and Traversal only differ in which functors they allow in place of f. As a consequence, optics of different kinds can be freely mixed, as long as there is a type which all of them fit. Here are some examples:

## Operators

Several lens combinators have infix operator synonyms, or at least operators nearly equivalent to them. Here are the correspondences for some of the combinators we have already seen:
| Prefix | Infix |
| view _1 (1,2) | (1,2) ^. _1 |
| set _1 7 (1,2) | (_1 .~ 7) (1,2) |
| over _1 (2 *) (1,2) | (_1 %~ (2 *)) (1,2) |
| toListOf traverse [1..4] | [1..4] ^.. traverse |
| preview traverse | ^? traverse |
lens operators that extract values (e.g. (^.), (^..) and (^?)) are flipped with respect to the corresponding prefix combinators, so that they take the structure from which the result is extracted as the first argument. That improves readability of code using them, as writing the full structure before the optics targeting parts of it mirrors how composed optics are written in large-to-small order. With the help of the (&) operator, which is defined simply as flip ($), the structure can also be written first when using modifying operators (e.g. (.~) and (%~)). (&) is particularly convenient when there are many fields to modify:

## A Swiss army knife

Thus far we have covered enough of lens to introduce lenses and show that they aren't arcane magic. That, however, is only the tip of the iceberg. lens is a large library providing a rich assortment of tools, which in turn realise a colourful palette of concepts. The odds are that if you think of anything in the core libraries there will be a combinator somewhere in lens that works with it. It is no exaggeration to say that a book exploring every corner of lens might be made as long as this one you are reading. Unfortunately, we cannot undertake such an endeavour right here. What we can do is briefly discussing a few other general-purpose lens tools you are bound to encounter in the wild at some point.

### State manipulation

There are quite a few combinators for working with state functors peppered over the lens modules. For instance:
* use from Control.Lens.Getter is an analogue of gets from Control.Monad.State that takes a getter instead of a plain function.
* Control.Lens.Setter includes suggestive-looking operators that modify parts of a state targeted a setter (e.g. .= is analogous to set, %= to over and (+= x) to over (+x)).
* Control.Lens.Zoom offers the remarkably handy zoom combinator, which uses a traversal (or a lens) to zoom into a part of a state. It does so by lifiting a stateful computation into one that works with a larger state, of which the original state is a part.
Such combinators can be used to write highly intention-revealing code that transparently manipulates deep parts of a state:

### Isos

In our series of Point and Segment examples, we have been using the makePoint function as a convenient way to make a Point out of (Double, Double) pair.
The X and Y coordinates of the resulting Point correspond exactly to the two components of the original pair. That being so, we can define an unmakePoint function...
... so that makePoint and unmakePoint are a pair of inverses, that is, they undo each other:
In other words, makePoint and unmakePoint provide a way to losslessly convert a pair to a point and vice-versa. Using jargon, we can say that makePoint and unmakePoint form an isomorphism.
unmakePoint might be made into a Lens' Point (Double, Double). Symmetrically. makePoint would give rise to a Lens' (Double, Double) Point, and the two lenses would be a pair of inverses. Lenses with inverses have a type synonym of their own, Iso, as well as some extra tools defined in Control.Lens.Iso.
An Iso can be built from a pair of inverses through the iso function:
Isos are Lenses, and so the familiar lens combinators work as usual:
Additionally, Isos can be inverted using from:
Another interesting combinator is under. As the name suggests, it is just like over, except that it uses the inverted Iso that from would give us. We will demonstrate it by using the enum isomorphism to play with the Int representation of Chars without using chr and ord from Data.Char explicitly:
newtypes and other single-constructor types give rise to isomorphisms. Control.Lens.Wrapped exploits that fact to provide Iso-based tools which, for instance, make it unnecessary to remember record label names for unwrapping newtypes...
... and that make newtype wrapping for instance selection less messy:

### Prisms

With Iso, we have reached for the first time a rank below Lens in the hierarchy of optics: every Iso is a Lens, but not every Lens is an Iso. By going back to Traversal, we can observe how the optics get progressively less precise in what they point to:
* An Iso is an optic that has exactly one target and is invertible.
* A Lens also has exactly one target but is not invertible.
* A Traversal can have any number of targets and is not invertible.
Along the way, we first dropped invertibility and then the uniqueness of targets. If we follow a different path by dropping uniqueness before invertibility, we find a second kind of optic between isomorphisms and traversals: prisms. A Prism is an invertible optic that need not have exactly one target. As invertibility is incompatible with multiple targets, we can be more precise: a Prism can reach either no targets or exactly one target.
Aiming at a single target with the possibility of failure sounds a lot like pattern matching, and prisms are indeed able to capture that. If tuples and records provide natural examples of lenses, Maybe, Either and other types with multiple constructors play the same role for prisms.
Every Prism is a Traversal, and so the usual combinators for traversals, setters and folds all work with prisms:
A Prism is not a Getter, though: the target might not be there. For that reason, we use preview rather than view to retrieve the target:
For inverting a Prism, we use re and review from Control.Lens.Review. re is analogous to from, though it gives merely a Getter. review is equivalent to view with the inverted prism.
Just like there is more to lenses than reaching record fields, prisms are not limited to matching constructors. For instance, Control.Lens.Prism defines only, which encodes equality tests as a Prism:
The prism and prism' functions allow us to build our own prisms. Here is an example using stripPrefix from Data.List:
prefixed is available from lens, in the Data.List.Lens module.
* Exercises
* Control.Lens.Prism defines an outside function, which has the following (simplified) type:
* outside :: Prism s t a b
* -> Lens (t -> r) (s -> r) (b -> r) (a -> r)
* Explain what outside does without mentioning its implementation. (Hint: The documentation says that with it we can "use a Prism as a kind of first-class pattern". Your answer should expand on that, explaining how we can use it in such a way.)
* Use outside to implement maybe and either from the Prelude:
* maybe :: b -> (a -> b) -> Maybe a -> b
* either :: (a -> c) -> (b -> c) -> Either a b -> c

## Laws

There are laws specifying how sensible optics should behave. We will now survey those that apply to the optics that we covered here.
Starting from the top of the taxonomy, Fold does not have laws, just like the Foldable class. Getter does not have laws either, which is not surprising, given that any function can be made into a Getter via to.
Setter, however, does have laws. over is a generalisation of fmap, and is therefore subject to the functor laws:
As set s x = over s (const x), a consequence of the second functor law is that:
That is, setting twice is the same as setting once.
Traversal laws, similarly, are generalisations of the Traversable laws:
The consequences discussed in the Traversable chapter follow as well: a traversal visits all of its targets exactly once, and must either preserve the surrounding structure or destroy it wholly.
Every Lens is a Traversal and a Setter, and so the laws above also hold for lenses. In addition, every Lens is also a Getter. Given that a lens is both a getter and a setter, it should get the same target that it sets. This common sense requirement is expressed by the following laws:
Together with the "setting twice" law of setters presented above, those laws are commonly referred to as the lens laws.
Analogous laws hold for Prisms, with preview instead of view and review instead of set:
Isos are both lenses and prisms, so all of the laws above hold for them. The prism laws, however, can be simplified, given that for isomorphisms preview i = Just . view i (that is, preview never fails):

### Polymorphic updates

When we look at optic types such as Setter s t a b and Lens s t a b we see four independent type variables. However, if we take the various optic laws into account we find out that not all choices of s, t, a and b are reasonable. For instance, consider the "setting twice" law of setters:
For "setting twice is the same than setting once" to make sense, it must be possible to set twice using the same setter. As a consequence, the law can only hold for a Setter s t a b if t can somehow be specialised so that it becomes equal to s (otherwise the type of the whole would change on every set, leading to a type mismatch).
From considerations about the types involved in the laws such as the one above, it follows that the four type parameters in law-abiding Setters, Traversals, Prisms and Lenses are not fully independent from each other. We won't examine the interdependency in detail, but merely point out some of its consequences. Firstly, a and b are cut from the same cloth, in that even if an optic can change types there must be a way of specialising a and b to make them equal; furthermore, the same holds for s and t. Secondly, if a and b are equal then s and t must be equal as well.
In practice, those restrictions mean that valid optics that can change types usually have s and t parametrised in terms of a and b. Type-changing updates in this fashion are often referred to as polymorphic updates. For the sake of illustration, here are a few arbitrary examples taken from lens:
At this point, we can return to the question left open when we presented the Lens type. Given that Lens and Traversal allow type changing while Getter and Fold do not, it would be indeed rash to say that every Lens is a Getter, or that every Traversal is a Fold. However, the interdependence of the type variables mean that every lawful Lens can be used as a Getter, and every lawful Traversal can be used as a Fold, as lawful lenses and traversals can always be used in non type-changing ways.

## No strings attached

As we have seen, we can use lens to define optics through functions such as lens and auto-generation tools such as makeLenses. Strictly speaking, though, these are merely convenience helpers. Given that Lens, Traversal and so forth are just type synonyms, their definitions are not needed when writing optics − for instance, we can always write Functor f => (a -> f b) -> (s -> f t) instead of Lens s t a b. That means we can define optics compatible with lens without using lens at all! In fact, any Lens, Traversal, Setter or Getting can be defined with no dependencies other than the base package.
The ability to define optics without depending on the lens library provides considerable flexibility in how they can be leveraged. While there are libraries that do depend on lens, library authors are often wary of acquiring a dependency on large packages with several dependencies such as lens, especially when writing small, general-purpose libraries. Such concerns can be sidestepped by defining the optics without using the type synonyms or the helper tools in lens. Furthermore, the types being only synonyms makes it possible to have multiple optic frameworks (i.e. lens and similar libraries) that can be used interchangeably.

## Further reading

* Several paragraphs above, we said that lens easily provides enough material for a full book. The closest thing to that we currently have is Artyom Kazak's "lens over tea" series of blog posts. It explores the implementation of functional references in lens and the concepts behind it in far more depth than what we are able to do here. Highly recommended reading.
* Useful information can be reached through lens' GitHub wiki, and of course lens' API documentation is well worth exploring.
* lens is a large and complex library. If you want to study its implementation but would rather begin with something simpler, a good place to start are minimalistic lens-compatible libraries such as microlens and lens-simple.
* Studying (and using!) optic-powered libraries is a good way to get the hang of how functional references are used. Some arbitrary examples:
** diagrams, a vector graphics library that uses lens extensively to deal with properties of graphic elements.
** wreq, a web client library with a lens-based interface.
** xml-lens, which provides optics for manipulating XML.
** formattable, a library for date, time and number formatting. Formattable.NumFormat is an example of a module that provides lens-compatible lenses without depending on the lens package.
* Lenses and functional references
* Solutions to exercises
* Advanced Haskell
* Monoids
* >> Applicative functors
* >> Foldable
* >> Traversable
* >> Arrow tutorial
* >> Understanding arrows
* >> Continuation passing style
* >> Zippers
* >> Lenses
* >> Comonads
* >> Value recursion (MonadFix)
* >> Effectful streaming
* >> Mutable objects
* >> Concurrency
* >> Template Haskell
* >> Type Families
* Haskell
* Haskell Basics
* >> Elementary Haskell
* >> Intermediate Haskell
* >> Monads
* Advanced Haskell
* >> Fun with Types
* >> Wider Theory
* >> Haskell Performance
* Libraries Reference
* >> General Practices
* >> Specialised Tasks