Optics

An optic is a first-class, composable notion of substructure. As a highly abstract concept, the idea can be approached by considering several examples of optics and understanding their common features. What are the possible relationships between some "outer" type S and some "inner" type A?

(For simplicity we will initially ignore the possibility of type-changing update operations, which change A to some other type B and hence change S to some other type T. These are fully supported by the library, at the cost of some extra type parameters.)

Optics.Iso: isomorphisms

First, S and A may be isomorphic, i.e. there exist mutually inverse functions to convert S -> A and A -> S. This is a somewhat trivial notion of substructure: A is just another way to represent "all of S".

An Iso' S A is an isomorphism between S and A, with the conversion functions given by view and review. For example, given

newtype Age = Age Int

there is an isomorphism between the newtype and its representation:

       coerced :: Iso' Age Int
view   coerced :: Age -> Int
review coerced :: Int -> Age

Optics.Lens: generalised fields

If S is a simple product type (i.e. it has a single constructor with one or more fields), A may be a single field of S. More generally, A may be "part of S" in the sense that S is isomorphic to the pair (A,C) for some type C representing the other fields. In this case, there is a projection function S -> A for getting the value of the field, but the update function (setting the value of the field) requires the "rest of S" and so has type A -> S -> S.

A Lens' S A captures the structure of A being a field of S, with the projection function given by view and the update function by set. For example, for the pair type (X,Y) there are lenses for each component:

     _1 :: Lens' (X,Y) X
     _2 :: Lens' (X,Y) Y
view _1 :: (X,Y) -> X
set  _2 :: Y -> (X,Y) -> (X,Y)

(Note that the update function could arguably have the more precise type A -> C -> S, since we do not expect the result of setting a field to depend on the previous value of the field. However, making C explicit turns out to be awkward, so instead we impose laws to require that the result of setting the field depends only on C, and, more generally, that the lens behaves as we would expect.)

Optics.Prism: generalised constructors

If S is a simple sum type (i.e. it has one or more constructors, each with a single field), A may be the type of the field for a single constructor of S. More generally, S may be isomorphic to the disjoint union Either D A for some type D representing the other constructors. In this case, projecting out A from S (pattern-matching on the constructor) may fail, so it has type S -> Maybe A. In the reverse direction we have a function of type A -> S representing the constructor itself.

A Prism' S A captures the structure of A being a constructor of S, with the partial projection function given by preview and the constructor function given by review. For example, for the type Either X Y there is a prism for each constructor:

        _Left  :: Prism' (Either X Y) X
        _Right :: Prism' (Either X Y) Y
preview _Left  :: Either X Y -> Maybe X
review  _Right :: Y -> Either X Y

Optics.Traversal: multiple substructures

Alternatively, S may "contain" the substructure A a variable number of times. In this case, the projection function extracts the (possibly zero or many) elements so has type S -> [A], while the update function may take different values for different elements so has type (A -> A) -> S -> S (though in fact more general formulations are possible).

A Traversal' S A captures the structure of A being contained in S perhaps multiple times, with the list of values given by toListOf and the update function given by over . For example, for the type Maybe X there is a traversal that may return zero or one element:

         traversed :: Traversal' (Maybe X) X
toListOf traversed :: Maybe X -> [X]
over     traversed :: (X -> X) -> Maybe X -> Maybe X

(In fact, traversals of at most one element are known as affine traversals, see Optics.AffineTraversal.)

In general

So far we have seen four different kinds of optic or "notions of substructure", and many more are possible. Observe the important properties they have in common:

• There are subtyping relationships between different optic kinds. Any isomorphism is trivially a lens and a prism (with no other fields or constructors, respectively). Any lens is a traversal (where the list of elements is always a singleton list), and any prism is also a traversal (where there will be zero or one element depending on whether the constructor matches). This was implicit in the fact that we used the same operators in multiple cases: view gives the projection function of both an isomorphism and a lens, but cannot be applied to a traversal.

• Optics can be composed. If S is isomorphic to U and U is isomorphic to A then S is isomorphic to A, and similarly for other optic kinds.

• Composition and subtyping interact: a lens and a prism can be composed, by first thinking of them as traversals using the subtyping relationship. That is, if S has a field U, and U has a constructor A, then S contains zero or one As that we can pick out with a traversal (but in general there is neither a lens from S to A nor a prism).

• Each optic kind can be described by certain operations it enables. For example lenses support projection and update, while prisms support partial projection and construction.

• Optics are subject to laws, which are necessary for the operations to make sense.

The point of the optics library is to capture this common pattern.

A key principle behind this library is the belief that optics are useful as an abstract concept, and that the purpose of types is to capture abstract concepts and make them useful. The programmer using optics should be able to think in terms of the abstract interface, rather than the details of the implementation, and implementation choices should (as far as possible) not dictate the interface.

Each optic kind is identified by a "tag type" (such as A_Lens), which is an empty data type. The type of the actual optics (such as Lens) is obtained by applying the Optic newtype wrapper to the tag type.

type Lens  s t a b = Optic  A_Lens NoIx s t a b
type Lens' s   a   = Optic' A_Lens NoIx s   a

NoIx as the second parameter to Optic indicates that the optic is not indexed. See the "Indexed optics" section below in Optics#indexed for further discussion of indexed optics.

The details of the internal implementation of Optic are hidden behind an abstraction boundary, so that the library can be used without needing to think about the particular implementation choices.

Specification of optics interfaces

Each different kind of optic is documented in a separate module describing its abstract interface, in a standard format with at least formation, introduction, elimination, and well-formedness sections. See "Optic kinds" below in Optics#optickinds for a list of these modules.

• The formation sections contain type definitions. For example Optics.Lens defines:

  -- Type synonym for a type-modifying lens.
  type Lens s t a b = Optic A_Lens NoIx s t a b
  

• The introduction sections describe the canonical way to construct each particular optic. Continuing with a Lens example:

  -- Build a lens from a getter and a setter.
  lens :: (s -> a) -> (s -> b -> t) :: Lens s t a b
  

• Correspondingly, the elimination sections show how you can destruct the optic into the pieces from which it was constructed.

  -- A Lens is a Setter and a Getter, therefore you can specialise types to obtain
  view :: Lens s t a b -> s -> a
  set  :: Lens s t a b -> b -> s -> t
  

• The computation rules tie introduction and elimination forms together. These rules are automatically fulfilled by the library (for well-formed optics).

  view (lens f g)   s ≡ f s
  set  (lens f g) a s ≡ g s a
  

• The well-formedness sections describe the laws that each optic should obey. As far as possible, all optics provided by the library are well-formed, but in some cases this depends on invariants that cannot be expressed in types. Ill-formed optics might behave differently from what the computation rules specify.

  For example, a Lens should obey three laws, known as GetPut, PutGet and PutPut. See the Optics.Lens module for their definitions. The user of the lens introduction form must ensure that these laws are satisfied.

• Some optic kinds have additional introduction forms, additional elimination forms or combinators sections, which give alternative ways to create and use optics of that kind. In principle these are expressible in terms of the canonical introduction and elimination rules.

• The subtyping section gives the "tag type" (such as A_Lens), which in particular is accompanied by Is instances that define the subtyping relationship discussed in the following section.

Subtyping

There is a subtyping relationship between optics, implemented using typeclasses. The Is typeclass captures the property that one optic kind can be used as another, and the castOptic function can be used to explicitly cast between optic kinds. Is forms a partial order, represented in the graph below. For example, a lens can be used as a traversal, so there are arrows from Lens to Traversal (via AffineTraversal) and there is an instance of Is A_Lens A_Traversal.

Introduction forms (constructors) return a concrete optic kind, while elimination forms (destructors) are generally polymorphic in the optic kind they accept. This means that it is not normally necessary to explicitly cast between optic kinds. For example, we have

view :: Is k A_Getter => Optic' k is s a -> s -> a

so view can be used with isomorphisms or lenses, as these can be converted to a Getter.

If an explicit cast is needed, you can use castOptic. This arises when you use optics of different kinds in a context that requires them to have the same type. For example [folded, traversed] gives a type error (since A_Traversal is not A_Fold) but [folded, castOptic traversed] works.

The optic kind module (e.g. Optics.Lens) does not list all ways to construct or use particular the optic kind. For example, since a Lens is also a Traversal, a Fold etc, so you can use traverseOf, preview and many other combinators with lenses.

Subtype hierarchy

This graph gives an overview of the optic kinds and their subtype relationships:

Optics hierarchy

In addition to the optic kinds included in the diagram, there are also indexed variants such as IxLens, IxGetter, IxAffineTraversal, IxTraversal, IxAffineFold, IxFold and IxSetter. These are explained in more detail in the "Indexed optics" section below in Optics#indexed.

Composition

Since optics are not functions, they cannot be composed with the (.) operator. Instead there is a separate composition operator (%). The composition operator returns the common supertype of its arguments, or generates a type error if the composition does not make sense.

The optic kind resulting from a composition is the least upper bound (join) of the optic kinds being composed, if it exists. The JoinKinds class computes the least upper bound given two optic kind tags. For example the constraint 'JoinKinds A_Lens A_Prism k' makes GHC infer that k must be An_AffineTraversal.

The join does not exist for some pairs of optic kinds, which means that they cannot be composed. For example there is no optic kind above both Setter and Fold:

>>> :t mapped % folded......A_Setter cannot be composed with A_Fold...

The (.) operator from Control.Category cannot be used to compose optics either, because it would not support type-changing optics or composing optics of different kinds.

The lens package is the best known Haskell library for optics, and established many of the foundations on which the optics package builds (not least in quite a bit of code having been directly ported). It defines optics based on the van Laarhoven representation, where each optic kind is introduced as a transparent type synonym for a complex polymorphic type, for example:

type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t

In contrast, optics tries to preserve an abstraction boundary between the interface of optics and their implementation. Optic kinds are expressed directly in the types, as Optic is an opaque newtype:

type Lens s t a b = Optic A_Lens NoIx s t a b

The choice of representation of Optic is then an implementation detail, not essential for understanding the library. (In fact, optics uses the profunctor representation rather than the van Laarhoven representation; this affects the optic kinds and operations that can be conveniently supported, but not the essence of the design.)

Our design choice to use opaque rather than transparent abstractions leads to various consequences, both positive and negative, which are explored in the following subsections.

Advantages of the opaque design

Since the interface is deliberately chosen rather than to some extent determined by the implementation, we are free to choose a more restricted interface where doing so leads to conceptual simplicity. For example, in lens, the view function can be used with a Fold provided the result type has a Monoid instance, and the multiple targets of the Fold will be combined monoidally. This behaviour can be confusing, so in optics a Fold cannot be silently used as a Getter, and we prefer to have view work on Getters and define a separate foldOf operator for use on Folds. (But the gview function is available for users who may prefer otherwise.)

In general, opaque abstractions lead to better results from type inference (the optic kind is preserved in the inferred type):

>>> :t traversed % to nottraversed % to not  :: Traversable t => Optic A_Fold '[] (t Bool) (t Bool) Bool Bool

Error messages are domain-specific:

>>> set (to fst)......A_Getter cannot be used as A_Setter...

Composing incompatible optics yields a sensible error:

>>> sets map % to not......A_Setter cannot be composed with A_Getter...

Since Optic is a rank-1 type, it is easy to store optics in a datastructure:

>>> :t [folded, backwards_ folded][folded, backwards_ folded] :: Foldable f => [Fold (f a) a]

It is possible to define aliases for optics without the monomorphism restriction spoiling the fun:

>>> let { myoptic = _1; p = ('x','y') } in (view myoptic p, set myoptic 'c' p)('x',('c','y'))

Finally, having an abstract interface gives more freedom of choice in the internal implementation. If there is a compelling reason to switch to an alternative representation, one can in principle do so without changing the interface.

Disadvantages of the opaque design

Since Optic is a newtype, other libraries that wish to define optics must depend upon its definition. In contrast, with a transparent representation, and since the van Laarhoven representations of lenses and traversals depend only on definitions from base, it is possible for libraries to define them without any extra library dependencies (although this does not hold for more advanced optic kinds such as prisms or indexed optics). To address this, the present library is split into a package optics-core, which has a minimal dependency footprint intended for use in libraries, and the "batteries-included" optics package for use in applications.

It is something of an amazing fact that the composition operator for transparent optics is just function composition. Moreover, since Haskell uses (.) for function composition, lens is able to support a pseudo-OOP syntax. In contrast, optics must use a different composition operator (%). Optic does not quite form a Category, thanks to type-changing optics.

Rather than emerging naturally from the definitions, opportunities for polymorphism have to be identified in advance and explicitly introduced using type classes. Similarly, the set of optic kinds and the subtyping relationships between them must be fixed in advance, and cannot be added to in downstream libraries. Thus in a sense the opaque approach is more restrictive than the transparent one. There are cases in lens where the types work out nicely and permit abstraction-breaking-but-convenient shortcuts, such as applying a Traversal as a traverse-like function, whereas optics requires a call to traverseOf.

More specific differences

The sections above set out the major conceptual differences from the lens package, and their advantages and disadvantages. Some more specific design differences, which may be useful for comparison or porting code between the libraries. This list is no doubt incomplete.

• The composition operator is (%) rather than (.) and is defined as infixl 9 instead of infixr 9.

• Fewer operators are provided, and some of them are not exported from the main Optics module. Import Optics.State.Operators if you want them.

• The view function and corresponding (^.) operator work only for Getters and have a more restricted type. The equivalent for Folds is foldOf, and you can use preview for AffineFolds. Alternatively you can use gview which is more compatible with view from lens, but it uses a type class to choose between view, preview and foldOf.

• Indexed optics are rather different, as described in the "Indexed optics" section below in Optics#indexed. All ordinary optics are "index-preserving", so there is no separate notion of an index-preserving optic.

• Each provides indexed traversals.

• firstOf from lens is replaced by headOf.

• concatOf from lens is omitted in favour of the more general foldOf.

• set' is a strict version of set, not set for type-preserving optics.

• Numbered lenses for accessing fields of tuples positionally are provided only up to _9, rather than _19.

• There are four variants of backwards for (indexed) Traversals and Folds: backwards, backwards_, ibackwards and ibackwards_.

• There is no Traversal1 and Fold1.

• There are affine variants of (indexed) traversals and folds (AffineTraversal, AffineFold, IxAffineTraversal and IxAffineFold). An affine optic targets at most one value. Composing a Lens with a Prism produces an AffineTraversal, so for example matching (_1 % _Left) is well-typed.

• Functions ifiltered and indices are defined as optic combinators due to restrictions of internal representation.

• We can't use traverse as an optic directly. Instead there is a Traversal called traversed. Similarly traverseOf must be used to apply a Traversal, rather than simply using it as a function.

• The re combinator produces a different optic kind depending on the kind of the input Iso, for example Review reverses to Getter while a reversed Iso is still an Iso. Thus there is no separate from combinator for reversing Isos.

• singular (isingular for indexed optics) doesn't produce a partial lens that might fail with a runtime error, but an affine traversal.

• <> cannot be used to combine Folds, so summing should be used instead (see the "Monoid structures" section below in Optics#monoids).

Talks

• (2020-10) User Friendly Optics - a talk about the optics library in comparison to the lens library by Andrzej Rybczak

• (2020-06) Basic optics: lenses, prisms, and traversals - an introductory talk about this library by Alejandro Serrano

• (2018-10) Profunctors and Data Accessors - a talk on basics of profunctors and how they relate to data accessors such as lenses, prisms and traversals by Andrzej Rybczak

• (2017-10) Through a Glass, Abstractly: Lenses and the Power of Abstraction - a talk on the principles behind this library with accompanying slides by Adam Gundry (but note that the design details of optics have changed substantially since this talk was given)

Articles

• (2020-01) Case study: migrating from lens to optics - a blog post by Oleg Grenrus, potentially useful if you wish to migrate an existing codebase to optics from lens

• (2017-04) Glassery and Indexed Profunctor optics - blog posts by Oleg Grenrus on the internal representations used by this library

• (2017-03) Profunctor Optics: Modular Data Accessors - a paper by Matthew Pickering, Jeremy Gibbons and Nicolas Wu

Libraries

• The lens package by Edward Kmett and contributors