codo-notation-orchard12

Abstract
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012
Dominic Orchard
Computer Laboratory, University of Cambridge, UK
dominic.orchard@cl.cam.ac.uk
The category-theoretic notion of a monad fortuitously matches the
underlying structure of various notions of effectful computation
thus it can be used for abstraction in both programming and semantics.
The utility and ubiquity of monads is such that some languages
provide notation to simplify programming with monads. Comonads,
the dual of monads, have been similarly applied in semantics
and programming but remain relatively under-utilised compared
with monads. There are several useful examples of comonads but
a lack of notation prevents wider adoption and indeed further understanding
of comonads as an abstraction mechanism. We propose
a lightweight syntax for programming with comonads in Haskell,
analogous to the do-notation for monads, accompanied by examples
of comonads in the notation. The utility of comonads compared
to monads is analysed and we present the case that, whilst
less diverse than monads, comonads are useful in programming.
1. Introduction
Concepts from category theory have proven extremely effective as
tools for abstraction in both language semantics and programming,
simplifying definitions and reasoning. A well known example is the
monad structure which Moggi applied to structure the semantics
of languages with computational effects such as non-determinism,
partiality, and state [8, 9]. Following the use of monads in semantics,
Wadler showed that monads can be used directly in programming
as a design pattern for organising programs and encapsulating
impure features in a pure language [20, 21]. Monads are so
effective as an abstraction technique that some languages provide a
lightweight syntax simplifying programming with monads, such as
the do-notation in Haskell and the let! notation in F# [13].
In the functional programming interpretation, a monad comprises
a parametric data type M and operations which provide
well-behaved composition to functions of type a → Mb. Thus,
monads provide abstraction for the composition of functions with
structured output. An example output structure encodes partiality,
or single exceptions, with the parametric type Ma = a + 1.
Comonads are the dual structure to monads providing abstraction
over composition of functions with structured input i.e. functions
of type Ca → b where C is a data type providing structure
to a function’s inputs. An example input structure encodes global
implicit parameters with the parametric type Ca = a × x, where x
is the type of some global parameter.
[Copyright notice will appear here once ’preprint’ option is removed.]
A Notation for Comonads
Alan Mycroft
Computer Laboratory, University of Cambridge, UK
am@cl.cam.ac.uk
There are various examples of comonads in functional programming
in the literature such as dataflow programming with
streams [18], attribute evaluation [16], array computations [11],
context-dependent computation [17], and more [6]. However,
comonads have been less widely accepted than monads.
The primary reason for the underuse of comonads in programming
is that there are fewer known useful examples, or at least less
diverse examples, compared to monads. For the examples that are
known, there is no language support to simplify programming with
these comonads. We conjecture that the lack of notation further impedes
use of comonads and fresh experimentation with comonads
as a design pattern for programming.
Presently, we propose a notation for programming with comonads
along with various practical examples written in the notation.
The specific contributions are:
• a lightweight notation for programming with comonads in
Haskell, called the codo-notation, which considerably simplifies
comonadic programming (Section 2)
• a simple desugaring of codo-notation into the operations of a
comonad (Section 3) and an accompanying equational theory
for the syntax (Section 4);
• various practical examples of comonads using the notation, including
lists (Section 2.1), arrays (Section 2.2), dataflow/streams
(Section 5.2), dynamic programming (Section 5.3), numerical
functions (Section 5.1), and implicit parameters (Section 6.2);
• discussion of the design of the codo-notation from the perspective
of language semantics and comparison to the analogous donotation
for monads (Section 6);
• discussion of extensions to the codo-notation (Section 8), and
comparison of codo-notation to Haskell’s rebindable syntax
and arrow notation (Section 7).
The codo-notation is provided using macros in GHC as a library
available at: http://github.com/dorchard/codo-notation.
2. Comonads and codo-notation
Comonads and codo-notation will be introduced concurrently in
the following two sections using two example comonads.
Section 2.1 provides an intuition for comonads in terms of composition
for functions with structured input and an introduction to
the basic binding structure of the codo-notation, using a comonad
of non-empty lists as an example. Section 2.2 provides an intuition
for comonads in terms of contextual computations and shows the
use of tuple patterns in codo-notation and the simplifications provided
when working with multi-parameter comonadic operations.
Array comonads will be used as examples.
2.1 Composing computations with structured input
In Haskell a comonad can be defined by a parametric data type and
an instance of the following type class:
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 1 2012/9/22

class Comonad c where
current :: c a → a
(≪=) :: (c a → b) → c a → c b
where current and ≪= are total functions and satisfy a number
of additional laws (Section 4). We pronounce the operator ≪= as
cobind. The names of the comonad operations vary in the literature
and existing usage.
The types of the operations are suggestive of their behaviour
which is further prescribed by the comonad laws. One intuition for
comonads, is of an abstraction for composing functions with structured
input, that is, for functions with input type of a parametric
data type common to each function.
Comonads for functions with structured input A simple intuition
for current is a prosaic function with structured input, where
the additional structure on the input is discarded and a particular
element extracted. The basic intuition for cobind is that a function
with structured input has its input structure propagated to the result.
An example input structure, for which comonads can provide a
well-behaved composition, is non-empty lists. The current operation
returns the head of the list, hence the non-empty restriction so
that current is total. The cobind operation is akin to map, except
that the parameter function is applied to successive suffixes of the
parameter list, rather than just single elements. For example:
sum ≪= [1, 2, 3, 4] ≡ [10, 9, 7, 4]
current ≪= [1, 2, 3, 4] ≡ [1, 2, 3, 4]
id ≪= [1, 2, 3, 4] ≡ [[1, 2, 3, 4], [2, 3, 4], [3, 4], [4]]
where sum :: Num a ⇒ [a ] → a.
The second example is an instance of one of the comonad laws,
discussed in Section 4. The third example shows the suffixes that
are passed to the parameter function by cobind.
The Comonad instance for (non-empty) lists is defined:
instance Comonad [ ] where
current (x : xs) = x
f ≪= [x ] = [f [x ]]
f ≪= x = (f x) : (f ≪= (tail x))
Comonads for composition Given a function f : c x → y and
function g : c y → z the composite, which we’ll write as g ˆ◦ f, is
defined by first applying cobind to f , thus (f ≪=) : c x → c y, and
then composing g using the usual composition operator:
g ˆ◦ f = g ◦ (f ≪=) : c x → z
Thus cobind provides the basis of composition. The comonad laws
follow from the requirement that this composition is associative
and has a left and right identity (Section 4).
Codo-notation abstracts composition The codo-notation provides
a let-binding-like syntax abstracting the use of cobind to
compose comonadic operations (operations with structured input).
The codo-notation is polymorphic in the underlying comonad, using
Haskell type classes for overloading.
For non-empty lists, an example composite operation computes
the averages of list suffixes (where fromIntegral is a cast from
integers to fractional numbers):
ave x = let s = sum ≪= x
l = length ≪= x
in (current s) / (fromIntegral $ current l)
This example can be written equivalently in codo-notation:
ave = codo x ⇒ s ← sum x
l ← length x
(current s) / (fromIntegral $ current l)
Applying ave to a list using cobind returns the suffix-list averages:
ave ≪= [1, 2, 3, 4] ≡ [2.5, 3.0, 3.5, 4.0]
Alternatively, ave can be applied directly to a list, returning the
average for that list, not for suffixes, e.g. ave [1, 2, 3, 4] = 2.5.
As seen in this example, the codo-notation primarily provides
an abstraction over cobind. A codo-block is parameterised, where
a pattern match between the codo keyword and double arrow ⇒
provides a binding site for the parameter. In the case of ave, the
pattern is a simple variable pattern.
For a variable pattern parameter, a codo-block is typed by the rule:
[varP]
Γ, x : c t ⊢c e : t ′
Γ ⊢ (codo x ⇒ e) : Comonad c ⇒ c t → t ′
where ⊢c types the binders of the codo-block. Since comonads
capture functions with structured input the parameter of a codoblock
is essential as it provides the input structure.
A codo-block has zero or more binding statements, of the form
p ← e, preceding a final result expression. A binding inside a
codo-block to a variable pattern is typed by the rule:
[varB]
Γ ⊢c e1 : t Γ, y : c t ⊢c e2 : t′
Γ ⊢c y ← e1; e2 : t ′
Variables bound within the codo-block (the local variables) are the
inputs of further expressions in the block. The presence of the toplevel
parameter means that every expression in the block has at
least one input. The interpretation of binding an expression is thus
composition of this expression as a function from its inputs with the
interpretation of the rest of the block. Thus in [varB] the binding of
e1 : t to y implies y : c t in the rest of the block.
The binding behaviour within a codo-block can be illustrated
when ave is applied to a list [1, 2, 3, 4] by showing the intermediate
values of bindings:
(codo x ⇒ y ← sum x -- x = [1, 2, 3, 4], sum x = 10
z ← length x -- y = [10, 9, 7, 4], length x = 4
... -- z = [4, 3, 2, 1]
) [1, 2, 3, 4]
The typing rules for codo-notation are collected in Figure 2.2.
Comonads are functors, cobind generalises map Haskell’s Functor
type class provides an operation for transforming the elements of a
parametric data type, of which map is the instance for lists:
class Functor f where fmap :: (a → b) → f a → f b
instance Functor [ ] where fmap = map
All comonads are functors where fmap can be defined in terms of
cobind and current:
cmap :: Comonad c ⇒ (a → b) → c a → c b
cmap f x = (f ◦ current) ≪= x
While fmap applies its parameter function to a single element,
cobind applies its parameter function to possibly the whole parameter
structure or a particular substructure, such as the suffix lists of
the non-empty list comonad. Thus cobind generalises fmap.
2.2 Contextual computations & multi-parameter operations
Much of the existing literature on comonads in programming describes
comonads in general as capturing notions of context dependence
(for example [17]). This contextual understanding provides
a useful intuition for comonads further than that provided by the
understanding of composition for functions with structured input.
In the contextual interpretation, a comonadic value of type c a is
a value of type a which is dependent on some notion of context or is
contextually situated i.e. it exists relative to some other information
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 2 2012/9/22

in the context of a computation. The current operation extracts a
non-context-dependent value, by evaluating a value c a at a known
context, perhaps a default context or some current context inside
the comonad. The cobind operation takes a function c a → b
from context-dependent values c a to non-context-dependent values
b and returns a function c a → c b which propagates the
context-dependence of the parameter c a by applying the parameter
function at all possible contexts to build a context-dependent
c b value. The cmap operation corresponds to the application of a
non-contextual function over a comonadic structure.
The contextual (or context-dependent) understanding of comonads
can be contrasted with the understanding of monadic values
m a as effectful (or effect-producing) computations of a value of
type a. The effectful understanding provides intuition about the use
of monads further than the intuition of monads as just an abstraction
for composition of functions with structured output a → m b.
The following comonad of arrays fits the contextual understanding
particularly well.
Example: modelling discrete, finite environments Many applications,
particular in scientific computing and graphics-oriented applications,
employ a computational pattern known as the stencil (or
structured grid) pattern. The stencil pattern is characterised by iteration
over the index space of an array, or collection of arrays,
which represent some discretised environments. An array can be
understood as defining a value which is dependent upon its position
in the array. Thus arrays are context-dependent values where
the context is the position in the array.
Cellular automata, such as Conway’s Game of Life, apply
the stencil pattern of computation, which Piponi pointed out is
comonadic [14]. We have previously used comonads as the basis
for a domain-specific language of stencil computations on arrays
[11], and Capobianco and Uustalu used comonads for reasoning
about cellular automata [4]. The examples here use operations
from image processing (convolutions) on one-dimensional arrays.
Cursored arrays Stencil computations can be captured succinctly
by the cursored (or pointed) array comonad. Its data type comprises
an array paired with an index called the cursor:
data PArray i a = PA (Array i a) i
where Array i a is the built-in array data type in Haskell, with
index type i and element type a. Thus a cursored array PArray i a
is a value a dependent upon a context of type i (its position within
the array) paired with a current context (the cursor).
The operations of the comonad are defined:
instance Ix i ⇒ Comonad (PArray i) where
current (PA a c) = a ! c
f ≪= (PA a c) =
let es ′ = map (λi → (i, f (PA a i))) (indices a)
in PA (array (bounds a) es ′ ) c
Thus current extracts the value at the current context (where ! is the
array indexing operation); cobind applies the parameter operation
f for every index of the array, passing the parameter array to f
with the cursor set to each index. The results of applying f to the
parameter array at each index is collected into a index-value pair
list from which is the result array is constructed.
To illustrate the definition of cobind, consider the following
helper function which returns the current context of an array:
context :: PArray i a → i
context (PA a c) = c
Applying context to an array using cobind returns the array where
the value of each element is its index e.g.
context≪= a0 a1 a2 . . . @c = 0 1 2 . . . @c
where @c denotes the cursor of the array.
The cursor of the returned array has the same cursor as the
parameter array, which allows array operations to be nested.
A useful example operation from image processing is the onedimensional
discrete Laplace transform:
laplace1D :: Fractional a ⇒ PArray Int a → a
laplace1D (PA a i) =
let (b1 , b2 ) = bounds a
in if (i > b1 ∧ i < b2 )
then a ! (i − 1) − 2 ∗ (a ! i) + a ! (i + 1)
else 0.0
In the contextual understanding, laplace1D computes a value for
the current context i from a local neighbourhood of values at
relative contexts i, i − 1, and i + 1. The operation can applied
over the entire index space of an array by cobind. A bounds check
is performed, since indices i − 1 and i + 1 will be out-of-bounds
at the edge of the array, thus a default value of 0.0 is returned for
the edge indices. Alternate comonadic definitions can be used to
abstract the bounds checking process [10].
Codo and context An example composite operation of the Laplace
operator followed by a local mean operation (which at each index
i computes the mean of the values at i, i − 1 and i + 1) is:
prog1 = codo x ⇒ y ← laplace1D x
z ← localMean1D y
current z
Within prog1 the context of the computation is fixed at the context
of the incoming parameter x. Thus, if context x = c then
context y = c = context z . Therefore current z extracts a value
from z at c. The preservation of the context throughout a codoblock
is a consequence of a property we call shape preservation of
comonads which will be discussed further in Section 4.1.
Multi-parameter operations Multi-parameter comonadic functions
are significantly more difficult to compose without codo.
An example operation is the pointwise addition of two comonad
values, which is polymorphic in the comonad since no comonadspecific
operations are used:
plus :: (Comonad c, Num a) ⇒ c a → c a → a
plus x y = current x + current y
Multi-parameter comonadic functions can be composed with other
operations naturally using codo-notation e.g.
prog2 = codo a ⇒ b ← localMean1D a
c ← laplace1D b
d ← plus b c
localMean1D d
The definition of plus can be inlined but is separate here for brevity.
Without codo, prog2 is considerably more difficult to write
since plus must be applied correctly to both parameters such that it
is applied pointwise. An equivalent program without codo is:
prog2 a = let b = localMean1D ≪= a
d = (λb ′ → let c = laplace1D ≪= b ′
in plus b ′ c) ≪= b
in localMean1D d
The plus operation is nested within a function applied to b using
cobind, and which has a nested use of cobind. The definition of
c is laplace1D applied to b ′ using cobind thus b ′ and c have the
same cursor and plus b ′ c is the pointwise addition.
The following is an incorrect use of plus for pointwise addition:
prog2bad a = let b = localMean1D ≪=a
c = laplace1D ≪=b
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 3 2012/9/22

d = (plus b) ≪=c
in localMean1D d
The first parameter b of plus has the same cursor as a whilst the
second parameter c, applied by cobind, has a varying cursor. Thus
d is not the pointwise addition of b and c, rather the addition of the
value at the (fixed) current context of b to each element in c.
The codo-notation therefore considerably simplifies the use of
multi-parameter operations, eliminating possible bugs from unsynchronised
cursors. If the unusual behaviour of prog2bad is intended
it can be encoded in the codo-notation using nested codo-blocks:
prog2 ′ = codo a ⇒ b ← localMean1Db a
(codo b ′ ⇒ c ← laplace1D b ′
d ← plus b c
localMean1D d) b
The plus operation is applied to b (not b ′ ) and c, where b is bound
in the outer codo and thus has its cursor fixed, whilst c is bound in
the inner codo and thus has its cursor varying. Thus, referencing
a comonadic variable bound outside of a codo block (even if it
is bound within an outer codo-block) implies that the variable is
unsynchronised with respect to those bound within the block.
Comonads of tuples The codo-notation can take multiple parameters
using a tuple pattern in the parameter to codo. For example,
the following program has tuple pattern (x, y) and computes the
pointwise addition of the Laplace transform of x and y:
prog3 :: PArray Int (Double, Double) → Double
prog3 = codo (x, y) ⇒ a ← laplace1D x
b ← laplace1D y
(current a) + (current b)
The type of prog3 shows that, instead of two parameters, it takes
a single comonadic parameter with tuple elements, of the form
c (a, b). However, inside the block x : c a and y : c b thus the
desugaring of codo unzips the parameter (Section 3). The intention
is that x and y are synchronised in their cursors. The corresponding
typing rule for tuples patterns is [tupP] in Figure 2.2.
To apply prog3 to a pair of arrays its parameters must first be
zipped which is provided by the czip operation of ComonadZip:
class Comonad c ⇒ ComonadZip c where
czip :: (c a, c b) → c (a, b)
For PArray, czip can be defined:
instance (Eq i, Ix i) ⇒ ComonadZip (PArray i) where
czip (PA a c, PA a ′ c ′ ) =
if (c �≡ c ′ ) then error "Cursors must be equal"
else let es ′′ = map (λi → (i, (a ! i, a ′ ! i))) (indices a)
in PA (array (bounds a) es ′′ ) c
Thus only arrays of the same shape and cursor can be zipped together.
For other comonads it is easier to relax this condition. In
the contextual understanding, the two parameter arrays are synchronised
in their contexts. The example of prog3 can therefore be applied
to two array parameters x and y by prog3 ≪= (czip (x, y))
A tuple pattern can also be used in a binding statement, typed by
rule [tupB] (Figure 2.2). For example, the following is equivalent
to prog3 by parameter/statement binding exchange (see Section 4):
prog3 ′ = codo z ⇒ (x, y) ← current z
a ← laplace1D x
b ← laplace1D y
(current a) + (current b)
[tupP]
[varP]
Γ ⊢ codo p ⇒ e : Comonad c ⇒ c t → t ′
Γ, x : c t ⊢c e : t ′
Γ ⊢ (codo x ⇒ e) : Comonad c ⇒ c t → t ′
Γ, x : c t, y : c t ′ ⊢c e : t ′′
Γ ⊢ (codo (x, y) ⇒ e) : Comonad c ⇒ c (t, t ′ ) → t ′′
[wildP]
Γ ⊢c e : t
Γ ⊢ (codo ⇒ e) : Comonad c ⇒ c a → t
[varB]
[tupB]
Γ ⊢c p ← e; e : t
Γ ⊢c e1 : t Γ, y : c t ⊢c e2 : t′
[letB]
3. Desugaring codo
Γ ⊢c y ← e1; e2 : t ′
Γ ⊢c e1 : (t1, t2)
Γ, x : c t1‘, y : c t2 ⊢c e2 : t ′
Γ ⊢c (x, y) ← e1; e2 : t ′
Γ, ⊢c e1 : t
Γ, x : t ⊢c e2 : t ′
Γ ⊢c let y = e1; e2 : t ′
Figure 1. Typing rules for codo
The translation of codo-notation is based on Uustalu and Vene’s
semantics for a context-dependent λ-calculus [17]. The translation
has two parts: translation of binding into composition via cobind
and management of the environment for the local variables bound
in the codo-block. The first part of the translation is explained by
considering a restricted codo-notation where only a single variable,
bound in the previous statement, is in scope of any expression.
Single-variable contexts Consider the following codo-block for
some comonad C and unary operations f and g:
foo1 = codo x ⇒ y ← f x; g y
The first statement of the block can be interpreted as a function
from the parameter x to its expression:
(λx → f x) : C x → y (1)
The second statement, which is the final result expression, can be
similarly interpreted as a function from y to its expression:
(λy → g y) : C y → z (2)
Both (1) and (2) are functions with structured input, thus the semantics
of foo1 is the comonadic composition of (1) and (2):
�foo1 � = (λy → g y) ◦ (cobind (λx → f x)) : Cy → z.
where we write cobind for the prefix version of ≪=.
Multiple-variable contexts The codo-notation however provides
multi-variable contexts, allowing the following example with binary
function h : Cx → Cy → z:
foo2 = codo x ⇒ y ← f x; h x y
where foo2 : Cx → z. The first statement cannot be interpreted
as before since the second statement uses both x and y, thus its
interpretation must return x along with the result of f x:
(λx → (current x, f x)) : C x → (x, y) (3)
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 4 2012/9/22

Applying current to x means that the cobind of (3), which has
type C x → C (x, y), returns the parameter x and the result of
f x synchronised in their contexts.
The interpretation of the second statement is a function which
takes a value C (x, y) and unzips it, binding the constituent values
to x and y in the scope of h x y:
(λenv → let x = cmap fst env
y = cmap snd env
in h x y) : C (x, y) → z (4)
The variables x and y are still synchronised at the same context
since cmap preserves the contextual properties of the comonad.
The translation of foo2 is the comonadic composition of (3) & (4):
�foo2� = (λenv → let x = cmap fst env
y = cmap snd env
in h x y) ◦ (cobind (λx → (current x, f x)))
3.1 General construction
The translation folds over the list of binding statements in a codoblock,
accumulating a comonadic environment of the local variables
bound thus far. The accumulated environment is structured
by right-nested tuples terminated by an empty tuple.
Thus, the actual translation of foo2 is:
�foo2� = (λenv → let y = cmap fst env
x = cmap (fst ◦ snd) env
in g x y)
◦ (cobind (λenv → (let x = cmap fst env in f x,
current env)))
◦ (cmap (λenv → (env, ())))
For the first statement of foo2 the environment contains just x
and has type C (x, ()); the environment of the second statement
contains x and y and has type C (y, (x, ())).
The interpretation is defined by a number of auxiliary interpretation
functions which return a Haskell function.
Top-level interpretation The top-level interpretation of a codoblock
has the form �codo p ⇒ e�, defined:
�codo x ⇒ e� = �x ⊢ e�c ◦ (cmap (λx → (x, ())))
�codo ⇒ e� = �reserved ⊢ e�c ◦ (cmap (λx → (x, ())))
�codo (x, y) ⇒ e� = �x, y ⊢ e�c ◦
cmap (λp → (fst p, (snd p, ())))
where �Γ ⊢ b�c is the interpretation for bindings within a codoblock
where Γ is the context of the local variables and b is the list
of statements in the block terminated by a single expression.
The top-level interpretation generalises easily to arbitrary variabletuple
patterns. In each case, ��c is composed first with a function
that converts the incoming parameter of the codo-block into the
correct form to be passed to the result of ��c.
Binding interpretation Given Γ = v0, . . . , vn, then �Γ ⊢ e�c
returns a Haskell function of type where ti is the type of the variable
vi and t is the type of e:
Comonad c ⇒ c (t0, (. . . , (tn, ()))) → t
Thus, the input of the function defined by ��c is comonadic with
right-nested tuples, terminated by the empty tuple, as its values.
The definition of ��c is:
�Γ ⊢ e�c = �Γ ⊢ e�exp
�Γ ⊢ x ← e; e ′ �c = �x, Γ ⊢ e ′ �c ◦
cobind (λenv →
(�Γ ⊢ e�exp env, current env))
The interpretation of an expression, on the right-hand side of a
binder or the last expression in the block, is given by �Γ ⊢ e�exp.
Expression interpretation Finally, �Γ ⊢ e�exp unzips the incoming
comonadic environment binding the values to the variables in
Γ with a local let-binding into the scope of the expression e.
�Γ ⊢ e�exp =
λenv → let {∀vn ∈ Γ} vn = cmap (fst ◦ snd n ) env in e
where snd n means n compositions of snd and snd 0 = id and
{∀vn ∈ Γ} is meta-level directive iterating over the variables in Γ.
Section 6 compares the translation of codo-notation with that of
the do-notation, and explains why the translation of codo-notation
is relatively more complex.
4. Equational theory
As shown in Section 2.1, the cobind operation of a comonad provides
composition for functions with structured input, defined:
(ˆ◦) :: Comonad c ⇒ (c y → z) → (c x → y) → c x → z
g ˆ◦ f = g ◦ (f ≪=)
The laws of a comonad are exactly the laws that guarantee this
composition is associative and has a left and right unit, provided by
current. The right-hand column of Figure 3.1(b) summaries these
properties of composition along with the corresponding comonad
law which provides that property of composition (labelled [C1-3]).
As there is no mechanism for enforcing such rules in Haskell the
programmer is expected to verify the laws on their own.
Given the desugaring of codo into the operations of a comonad,
the comonad laws imply equational rules on the syntax of codonotation
which is given in the left-hand column of Figure 3.1(b).
Figure 3.1(a) gives properties of the the top-level codo-block
which following from its translation.
Section 2.2 introduced the ComonadZip type class which provides
the operation: czip : (c a, c b) → c (a, b). This operation
is that of a (semi)-monoidal functor which may satisfy various
laws with respect to the comonad (see the discussion of (semi)monoidal
comonads in [17]). The following property, which we
call idempotency of the semi-monoidal functor, frequently holds
of comonad/czip implementations:
czip (x, x) ≡ cmap (λx → (x, x)) x (5)
This property implies syntactic laws on codo shown in Figure
3.1(c), relating tuple patterns and the use of czip. For each
rule involving a tuple pattern there is an equivalent rule derived
from the parameter/statement exchange rule in Figure 3.1(a).
There are many possible laws which depend on other conditions
or operations. We included the Figure 3.1(c) in particular as the
idempotency property frequently holds.
4.1 Shape preservation
An interesting derived property of comonads is shape preservation.
The shape of a data type is its structure without any values i.e.
shape = cmap (const ())
where const x = λ → x. For example, the shape of a list is just
the cons-cells, without any values, or in this case the unit value ().
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 5 2012/9/22

codo x ⇒ z ← (codo y ⇒ e1) x
e2
Syntactic property Comonad property
(a). Pure rules
codo x ⇒ f x ≡ f (codo-η)
≡ codo x ⇒ y ← current x
z ← e1
codo (x, y) ⇒ e ≡ codo z ⇒ (x, y) ← current z
e
codo x ⇒ y ← current x
f y
codo x ⇒ y ← f x
current y
codo y ⇒ w ← e1
codo x ⇒ z ← e2
e3) y
e2
(b). Comonad laws
(codo-β)
(parameter/statement binding exchange)
≡ codo x ⇒ f x (right unit) f ˆ◦ ˆ
id ≡ f
⇒ [C1] current ≪= x ≡ x
≡ codo x ⇒ f x (left unit) ˆ id ˆ◦ f ≡ f
⇒ [C2] current (f ≪=x) ≡ f x
≡ codo x ⇒ y ← current x
w ← e1
z ← e2
e3
≡ codo x ⇒ z ← (codo y ⇒ w ← e1
e2) x
e3
(c). Additional rules (if conditions met)
codo (b, c) ⇒ f (czip (b, c)) ≡ codo (b, c) ⇒ z ← (current b, current c)
f z
codo x ⇒ (a ′ , b ′ ) ← czip (a, b)
f a ′ b ′
≡ codo x ⇒ f a b
A consequence of the comonad laws is that, for any function
f : c a → b, the function (cobind f ) : c a → c b preserves the
shape of the incoming structure in its result. For example, with the
list comonad of Section 2.1, for any function f :[a ] → b, cobind f
is a function which given a list of length n returns a list of length
n. This shape preservation property can be state formally as:
(∀f) shape ◦ (cobind f ) ≡ shape (6)
Appendix A gives the proof, which holds for all comonads.
5. Further examples
So far we have seen just two example comonads: non-empty lists
and cursored arrays. Here we show three more examples, of numerical
functions, streams, and dynamic programming. These three
examples will be united by a single comonad called the costate, or
in-context comonad. The stream and dynamic programming examples
make use of recursively defined comonad operations.
5.1 Parameterised Computations
A comonad of parameterised values has data type C a = x → a
where x is a fixed parameter type which has a monoidal structure.
An instance with real-number parameters (i.e. x = R) can be used
to structure numerical analysis problems over numerical functions.
In Haskell, the comonad of R-parameterised values is defined:
instance Comonad ((→) Double) where
current f = f 0.0
k≪=f = λx ′ → k (λx → f (x + x ′ ))
The cobind operation takes a comonadic operation k : (Double →
a) → b and numerical function f : Double → a returning a
Figure 2. Equational laws for the codo-notation
(associativity) h ˆ◦ (g ˆ◦ f) ≡ (h ˆ◦ g) ˆ◦ f
⇒ [C3] g ≪= (f ≪= x)
≡ (λx ′ → g (f ≪= x ′ )) ≪= x
(iff x is not free in e1)
– (idempotent monoidal functor)
czip (x, x) =
———-cmap (λx → (x, x)) x
transformed numerical function f ′ = k≪=f : Double → b where
the value of f ′ at x ′ is calculated by k applied to the function f
shifted by x ′ . In the contextual intuition, the context is the amount
by which f has been shifted. The current operation returns the value
of the function at the origin. In the contextual intuition the origin
provides the value at the current context (the current shift position).
An example operation is numerical differentiation defined:
differentiate f = (f 0.01 − f 0.0) / 0.01
Since cobind passes the f shifted by x ′ to differentiate then f 0.0
means f x ′ . The value by which f is shifted is unknown within a
comonadic operation thus the comonad is context-oblivious.
The following operation computes which values of a function
are local minima by testing the first and second derivatives:
minima = codo f ⇒ f ′ ← differentiate f
f ′′ ← differentiate f ′
(current f ′ ≈ 0) ∧ (current f ′′ < 0)
Another useful numerical analysis operation is to approximate
a functions as a series of polynomials, such as in the MacLaurin
series defined:
f(x) ≈ f(0) + f ′ (0)
1! x + f ′′ (0)
2! x2 + f ′′′ (0)
3! x3 + . . .
Since the context i.e. the amount by which a function has been
shifted is unknown, a MacLaurin operation for the numerical function
comonad is problematic because (1) each term of the series
uses the current context x in its calculation (2) each term accesses
the value of the corresponding derivative at the origin. Since f is
shifted by an unknown amount the actual origin value cannot be accessed.
A MacLaurin operations requires the context to be known.
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 6 2012/9/22

A possible solution is to transform the parameter numerical
function such that it remembers its context by returning a pair of
f x and x itself i.e. λx → (f x, x). A tuple pattern can then split
this input into the original parameter function f and essentially the
identity function which provides the corresponding context x:
m3 :: (Double → (Double, Double)) → Double
m3 = codo (f , x) ⇒ f ′ ← differentiate f
f ′′ ← differentiate f ′
f (−current x)
+ (f ′ (−current x)) ∗ (current x)
+ (f ′′ (−current x)) / 2 ∗ (current x) ∗∗ 2
where x : Double → Double and f : Double → Double.
Thus, the MacLaurin approximation of a function can be computed:
maclaurin3 f = m3 ≪=(λx → (f x, x))
Context-oblivious and context-aware operations The operations
on numerical functions here fall into two categories:
1. context-oblivious e.g. pointwise ops, differentiate, minima
2. context-aware e.g. MacLaurin series.
Context-oblivious operations either do not use the value of the
context, such as pointwise operations, or only use it relatively such
as differentiate or the laplace1D operator from Section 2.2.
Context-aware operations have their behaviour determined by
the context. For example, in the MacLaurin series the value of the
context is used in the calculation and is used to access absolute
contexts (the origin). Since the numerical function comonad uses
shifts, the current context is unknown. The work-around above used
tuple patterns and a transformation of a numerical function into a
function returning value-parameter pairs.
The pattern of value-parameter pairs can be abstracted as a
comonad of parameterised values paired with a particular parameter
Ca = (x → a) × x (resembling cursored arrays). This
comonad is called the costate comonad [17] 1 although we prefer
the name in-context comonad as ‘costate’ is less intuitive. The data
type is:
data InContext c a = InContext (c → a) c
where c is the type of contexts. The InContext comonad for any
context type is defined:
instance Comonad (InContext c) where
current (InContext a c) = x c
(InContext x c) =≫ k =
InContext (λc ′ → k (InContext x c ′ )) c
Thus, current extracts the current context and cobind returns an incontext
value whose value at context c ′ is computed from k applied
to the parameter in-context value at c ′ .
The MacLaurin example can be rewritten:
m3 :: InContext Double Double → Double
m3 = codo f ⇒ f ′ ← differentiate f
f ′′ ← differentiate f ′
x ← context f
(f ‘at‘ 0) + (f ′ ‘at‘ 0) ∗ (current x)
+ (f ′′ ‘at‘ 0) / 2 ∗ (current x) ∗∗ 2
using helper functions on contexts:
1 The phrase costate is due to the relation between the state monad and
costate comonad, which are induced from the same pair of adjoint functors.
The product functor DX = A × X, which is left adjoint to the exponent
functor T X = X → A, thus D ⊣ T , induces the state monad T DA =
X → (A × X) and the costate comonad DT A = (X → A) × X.
context (InContext x c) = c
at (InContext x c) c ′ = x c ′
The InContext comonad has many practical uses, for example the
cursored array example is isomorphic to an instance of InContext
with a context of indices within the arrays boundaries. The next
example uses the InContext comonad for stream programming.
5.2 Streams for Dataflow Programming
Uustalu and Vene showed that the Lucid dataflow language can be
given a semantics in terms of a stream comonad, providing an interpreter
of higher-order Lucid programs written in an AST format
i.e. a deep-embedded DSL is provided [18]. Using codo-notation
the first-order fragment of Lucid can be embedded directly into
Haskell as a shallow-embedded DSL where the stream comonad
is the InContext comonad with Int contexts:
type Stream a = InContext Int a
The behaviour of cobind can be illustrated for InContext Int a by
the following informal definition, where 〈a, b, c, . . .〉@x represents
an infinite stream in context x:
〈x0, x1, . . .〉@c =≫ f = 〈f 〈x0, x1, . . .〉@0,
f 〈x0, x1, . . .〉@1, . . .〉@c
Lucid is essentially a calculus of recursive, infinite stream equations.
Two key combinators are next and fby (followed by) which
have behaviour [19]:
next 〈x0, x1, x2, . . .〉 = 〈x1, x2, . . .〉
〈x0, x1, x2, . . .〉 fby 〈y0, y1, y2, . . .〉 = 〈x0, y0, y1, . . .〉
The next operator performs lookahead in a stream. The fby operator
delays a stream by the first element of another and is useful for
defining guarded recursion. For example, the stream of natural
numbers can be defined recursively in Lucid as:
n = 0 fby n + 1
where 0 and 1 are constant streams and + is pointwise addition.
In Haskell, the core non-pointwise operations of Lucid can be
defined for InContext as:
fby :: Stream a → Stream a → a
fby (InContext s c) (InContext t d) =
if (c ≡ 0 ∧ d ≡ 0) then s 0 else t (d − 1)
next :: Stream a → a
next (InContext s c) = s (c + 1)
constant :: a → Stream a
constant x = InContext (λ → x) 0
To define the stream of natural numbers we first define a nonrecursive
operator with parameter n for the recursive result:
nat ′ :: Num a ⇒ Stream a → a
nat ′ = codo n ⇒ n ′ ← (current n) + 1
(constant 0) ‘fby‘ n ′
The recursive “knot” must be tied such that the result of cobind on
nat ′ is passed to itself. A suitable combinator is:
cfix :: Comonad c ⇒ (c a → a) → c a
cfix f = f ≪= (cfix f )
The stream of natural numbers can then be calculated by:
nat = cfix nat ′ ≡ 〈0, 1, 2, . . .〉@⊥
The definition of cfix results in an undefined cursor for nat since
the operation c a → a recursively defines just the a-valued parts
of the stream. In some cases, a well-defined cursor is preferable. An
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 7 2012/9/22

alternative approach internalises the definition of cfix by binding a
recursive call in the codo-block e.g.
nat = codo n ⇒ n ′ ← (nat n) + 1
(constant 0) ‘fby‘ n ′
The stream of natural numbers can thus be applied by passing
in any stream to the cobind of nat which provides the stream
structure, including the cursor, but has its values ignored:
(nat≪=(constant ())) ≡ 〈0, 1, 2, . . .〉@0
An example using next is the howfar operation (defined in the
original Lucid book [19]) which takes an input stream of numbers
and returns a stream of the “distance” to a value of 0 in the input
stream at the corresponding position e.g.
howfar 〈6, 1, 5, 0, 3, 0, . . .〉 = 〈3, 2, 1, 0, 1, 0, . . .〉
The howfar function can be written recursively as:
howfar = codo x ⇒ x ′ ← next x
if (current x ≡ 0)
then 0 else 1 + (howfar x ′ )
5.3 Dynamic programming
Lucid can be generalised to multi-dimensional streams essentially
modelling infinite arrays [3]. Such computations have the same
comonadic structure as before, using InContext, but with contexts
of Int tuples. Multi-dimensional recursive streams are convenient
for defining dynamic programming problems [15].
We generalise here the Lucid example to multi-dimensional
streams with a specialised comonad for two-dimensional dynamic
programming problems with type:
data DynP x a = DynP (InContext (Int, Int) a) x x
where x is the type of the initial parameters to the algorithm. We
give a brief description of the Levenshtein algorithm for computing
the edit distance between two strings as an example to show the
power of comonads and codo. The definition in codo-notation is:
levenshtein :: DynP String Int → Int
levenshtein =
codo x ⇒ -- Initialise first row and column
d ← levenshtein x -- recursive call
dn ← (current d) + 1
d0 ← (constant 0) ‘fbyX ‘ dn
d ′ ← d0 ‘fbyY ‘ dn
-- Shift (-1, 0), (0, -1), (-1, -1)
d w ← d ‘at‘ (−1, 0)
d n ← d ‘at‘ (0, −1)
d nw ← d ‘at‘ (−1, −1)
d ′′ ← if (paramX d ≡ paramY d)
then current d nw
else minimum [(current d w) + 1,
(current d n) + 1,
(current d nw) + 1]
d ′ ‘thenXY ‘ d ′′
Lines 2-5 in the codo-block recursively define the top-most
row and left-most column of the two-dimensional as the stream of
natural numbers using two-dimensional followed by operators e.g.
fbyX :: DynP x a → DynP x a → a
fbyX (DynP (InContext s (c1 , c2 ) ))
(DynP (InContext t (c1 ′ , c2 ′ ) ))
= if (c1 ≡ 0 ∧ c1 ′ ≡ 0) then s (0, c2 )
else t (c1 ′ − 1, c2 ′ )
The paramX and paramY operations extract elements from initial
parameters of the algorithm at the current context in the x and y
dimensions respectively e.g.
paramX :: DynP String a → Char
paramX (DynP (InContext c@(c1 , c2 )) x y) = x !! c1
The thenXY operator is a combination of next and fby operations
over both dimensions which takes two infinite arrays and
combining them such that the first column and row are from the
first parameter and the rest of the elements from the second:
thenXY :: DynP x a → DynP x a → a
thenXY (DynP (InContext s (c1 , c2 )) )
(DynP (InContext t (c1 ′ , c2 ′ )) ) =
if ((c1 ≡ 0 ∧ c1 ′ ≡ 0) ∨ (c2 ≡ 0 ∧ c2 ′ ≡ 0))
then s (c1 , c2 )
else t (c1 ′ , c2 ′ )
A sample usage, with some suitable output function, is:
> let x = DynP (InContext ⊥ (0, 0)) (" hello") (" hey")
> levenshtein ≪= x
’ ’ ’h’ ’e’ ’l’ ’l’ ’o’
’ ’ [0, 1, 2, 3, 4, 5]
’h’ [1, 0, 1, 2, 3, 4]
’e’ [2, 1, 0, 1, 2, 3]
’y’ [3, 2, 1, 1, 2, 3]
where ⊥ can be used for the initial value of the InContext part
of DynP since the values of the parameter are never accessed.
Efficiency Functions in Haskell are not memoized (in their inputs
and outputs) thus the Lucid and dynamic programming examples
are inefficient incurring much recalculation. A more efficient
solution can be provided by isomorphic non-function representations
which Haskell memoizes by its call-by-need semantics, such
as lists for streams and arrays for the dynamic programming.
6. Comparing codo- and do-notation
While comonads and monads are dual, the codo- and do-notation
(for programming with monads) do not appear to be dual. Both provide
let-binding syntax for composition of comonadic and monadic
operations respectively. However, codo-blocks are parameterised,
with type c a → b for a comonad c, whilst do-blocks are unparameterised,
with type m a for a monad m. Since comonads abstract
functions with structured input the parameter to a codo-block
is important. In the do-notation, expressions have implicit input via
their free variables where Haskell’s own scoping mechanism can
be reused for handling the local variables in a do-block.
Section 6.1 explains the reasons behind the codo- and donotation
differences in more detail, and also shows why the translation
of the codo-notation is more complicated than the translation
of the do-notation. Section 6.2 compares the notations directly for
computations with implicit parameters which can structured equivalently
by the reader monad and the product (coreader) comonad.
6.1 Asymmetry in the notations
The distinction between codo- and do-notation can be understood
from the perspective of the notations as internal domain-specific
languages, for contextual and effectful computations respectively,
with their semantics defined by the translation to Haskell. This
approach is similar to that of categorical semantics where a typed
program is given a denotation as a morphism 2 , in some category,
mapping from the inputs of a program to the outputs.
2 Morphisms generalise the notion of function. Readers unfamiliar with
category theory may safely replace ‘morphism’ with ‘function’ here.
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 8 2012/9/22

Categorical semantics approach For the simply-typed λ-calculus,
the traditional approach pioneered by Lambek and Scott recursively
maps the type derivation of an expression to a morphism [7]:
�Γ ⊢ e : τ� : (�τ0� × . . . × �τn�) −→ �τ�
where Γ = x0 : τ0, . . . xn : τn. Thus, an expression e of type τ
with a context of free-variable typing assumptions Γ is modelled as
a morphism which maps from a product of the values of the free
variables as inputs to a result as the output. From now on we will
elide �� brackets on types in the morphisms for brevity.
Categorical semantics for effectful computations Moggi showed
that effectful computations can be given a semantics in terms of a
Kleisli category which has morphisms with structured output of
type a → m b for a monad m [8, 9]. The denotations are:
�Γ ⊢ e : τ� : (�τ0� × . . . × �τn�) −→ m �τ�
again where Γ = x0 : τ0, . . . xn : τn.
In Moggi’s calculus, let-binding follows the traditional approach
of internalising substitution (whether this is call-by-value
or call-by-name with respect to effects depends on the particular
monad). The semantics for let-binding corresponds to composition
of the denotations, provided by the bind operation of a monad.
However, handling multi-variable environments requires a strong
monad which has an additional operation called strength. The effectful
semantics for let-binding is:
��
(where f : a → b is written a b and composition is
expressed by concatenation of two arrows)
�Γ ⊢ e : τ� = g : Γ → m τ
�Γ, x : τ ⊢ e ′ : τ ′ � = g ′ : Γ × τ → m τ ′
�Γ ⊢ let x = e in e ′ : τ ′ � :=
Γ 〈id,g〉 ��
Γ × m τ strength ��
m (Γ × τ)
f
bind g′
��
m τ ′
where 〈f, g〉 is the function pairing: λx → (f x, g x), bind is
the prefix version of Haskell’s >= operator and strength provides
distributivity of × over m:
strength : (a × m b) → m (a × b)
bind : (a → m b) → (m a → m b)
The do-notation does not provide a full semantics for a language
with effects, but instead provides just a semantics for effectful letbinding
embedded in Haskell. This embedding can be simplified by
reusing Haskell’s scoping mechanism.
The do-notation In Haskell, all monads are strong with a canonical
strength operator:
strength :: Monad m ⇒ (a, m b) → m (a, b)
strength (a, mb) = mb >= (λb → return (a, b))
It is straightforwardly proved that this definition of strength satisfies
the properties of a strong monad (see [8] for these properties).
This definition of strength uses just the core monad operations
and the scoping mechanism of Haskell. Using this definition
of strength, and simplifying according to the monad laws, gives a
the semantics where Haskell’s scoping mechanism alone provides
the semantics of multi-variable contexts for effectful let-binding.
Thus the translation of do is relatively simple:
Γ ⊢ e : m τ Γ, x : τ ⊢ e ′ : m τ ′
Γ ⊢ �do x ← e; e ′ � : m τ ′ ≡ Γ ⊢ e >= (λx → e ′ ) : m τ ′
Thus the inputs to effectful computations need not be made explicit
and a do-block has type m a.
Categorical semantics for contextual computations The dual of
Moggi’s semantics interprets expressions in a coKleisli category
whose morphisms have structured input (c a → b for a comonad
c). The denotations are given by:
�Γ ⊢ e : τ� : c (�τ0� × . . . × �τn�) −→ �τ�
For a comonadic semantics the structure c is over the context of
free-variables. Contextual let-binding with multi-variable contexts
can be defined similarly to let for effectful computations:
�Γ ⊢ e : τ� = g : c Γ → τ
�Γ, x : τ ⊢ e ′ : τ ′ � = g ′ : c (Γ × τ) → τ ′
�Γ ⊢ let x = e in e ′ : τ ′ � :=
c Γ
〈id,cobind g〉
��
c Γ × cτ cstrength ��
c (Γ × τ)
Again, a strength-like operation is used, of type:
cstrength :: Comonad c ⇒ (c a, c b) → c (a, b)
g ′
��
τ ′
which corresponds to the czip operation of a semi-monoidal
comonad (see Section 4). Whilst strength for monads has a canonical
definition in terms of bind, return, and Haskell’s scoping mechanism
there is no such definition of cstrength which satisfies the
required properties (which are the laws of monoidal comonad [17]).
Thus the scoping mechanism of Haskell cannot be reused as it does
not provide comonadic structuring of the variables in the context.
Thus, for the codo-notation the multi-variable comonadic contexts
must be modelled explicitly as seen in the translation of codonotation
(Section 3) resulting in the relatively more complicated
translation of codo-notation compared with that of do-notation.
In our translation of codo an alternate approach is used:
�Γ ⊢ e : τ� = g : c Γ → τ
�Γ, x : τ ⊢ e ′ : τ ′ � = g ′ : c (Γ × τ) → τ ′
�Γ ⊢ let x = e in e ′ : τ ′ � :=
c Γ cobind〈current,g〉 ��
c (Γ × τ)
g ′
��
′
τ
where 〈current, g〉 : c Γ → Γ × τ.
Although this approach does not provide any simplifications in
terms of the handling of contexts it does not require a definition
of cstrength/czip. This approach is equivalent to the cstrength
approach if cstrength is idempotent (see Section 4).
6.2 Implicit parameters in codo- and do-notation
The product comonad, sometimes called the coreader comonad,
is a simple comonad encoding the notion of implicit parameters
threaded through a computation. It has the following definition:
type CoReader p a = (a, p)
instance Comonad ((, ) p) where
current (p, a) = a
(p, a) =≫ f = (p, f (p, a))
Thus cobind simply passes the implicit parameter unchanged to the
parameter function and to the output of the cobind. The implicit
parameter can be accessed by the operation:
ask (p, a) = p
Interestingly, the product/coreader comonad is isomorphic to
the reader monad 3 . The reader monad also structures computations
3 Naming the product comonad ‘coreader’ is perhaps misleading: the product
is isomorphic to the reader monad and thus provides the same functionality
but it is not a dual (whatever that might mean).
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 9 2012/9/22

with an implicit parameter, abstracting the threading of the parameter
through a computation. The reader monad has the following
type and monad instance:
type Reader p a = p → a
instance Monad ((→) p) where
return x = (λ → x)
x >= f = (λp → f (x p) p)
Thus bind returns a computation with a parameter x that is passed
to the argument and result of a monadic operation. As with the
product comonad an ask operation returns the implicit parameter:
askM :: Reader p p
askM = id
The reader monad and coreader comonad capture the same notion
of computation since there is an isomorphism between the monadic
and comonadic operations provided by curry/uncurry:
(a × p) → b
��
uncurry
curry ��
(a → (p → b))
The following example uses the reader monad with do-notation
to abstract an implicit parameter, where f :String → Reader Int Int
is some function which may depend on the implicit parameter:
foo :: Reader Int Int
foo = do x ← f "test"
y ← askM
return (x ∗ y)
The equivalent example in the codo-notation, with f ′ = (uncurry f ):
CoReader String Int → Int, is:
foo ′ :: CoReader a Int → Int
foo ′ = codo ⇒ s ← "test"
x ← f ′ s
y ← ask x
(current x) ∗ (current y)
There are three significant features of foo ′ .
Firstly, foo ′ has parameter matched by the wildcard pattern (see
rule [wildP], Figure 2.2) thus the values within the input structure
are never used. The parameter to the block is still required since it
provides the implicit parameter of type Int to the block.
Secondly, the argument to f ′ is first bound to a variable since it
must be imbued with the comonadic structure to pass the implicit
parameter to f ′ .
Thirdly, ask is passed a parameter x but any local variable
(s, x, or y) would suffice since ask ignores the values of the
input structure and extracts only the implicit parameter from the
incoming CoReader structure. By shape preservation every local
variable has the (same) implicit parameter.
Since the intention of CoReader is to abstract implicit parameters
it seems a shame that ask should have to be given an argument
at all since any local variable will pass the current context. To simplify
such cases, the codo-notation provides allows a wildcard as
an expression where :: c (). Thus, the current comonadic structure
of the codo-block can be passed, ignoring any particular values
inside the structure. This notation dualises the use of a wildcard pattern
in the bindings of do-notation e.g. ← print "42" where the
intention is that only the structure, or effects, are important, not the
values inside the structure.
The wildcard expression can be used in previous examples.
For example, the recursively defined natural number stream had a
parameter providing only the stream structure, not any values, thus
it can be rewritten:
nat = codo ⇒ n ′ ← (nat ) + 1
(constant 0) ‘fby‘ n ′
Note that the codo-notation does not allow a wildcard pattern in
a binding statement since by shape preservation such a binding is
redundant as binding does not affect a computation in itself. Thus:
codo x ⇒ ← f x; g x ≡ codo x ⇒ g x
7. Related Work
7.1 Rebindable syntax
GHC provides an extension for rebindable-syntax, allowing Haskell’s
core syntax to be overloaded. For the do-notation the rebindablesyntax
extension suppresses the usual requirement that the operations
in the desugaring of do-notation belong to the Monad type
class. Instead the do-notation uses whatever >= operation is in
scope, regardless of its type.
Can the rebindable-syntax extension be used to implement
codo-notation by defining bind as cobind? Both bind and cobind
take a parameter function, but for bind it is the second parameter
while for cobind it is the first:
( >=) :: m a → (a → m b) → m b
(≪=) :: (c a → b) → c a → c b
Thus, cobind should be flipped in the definition of bind:
x >= f = flip (≪=)
Recall that: �do x ← e1; e2� = e1 >= (λx → e2).
Therefore, an expression bound to a variable must have type c a. A
comonadic function could thus be wrapped in do-notation as such:
foo x = do {x ′ ← x; f x ′ }
which desugars to (λx → x >= (λx ′ → f x ′ )) i.e. cobind f .
Composing operations is more difficult; the following is no use:
foo2 x = do {x ′ ← x; y ′ ← f x ′ ; g y ′ }
since f x ′ : b not f x ′ : c b. Instead, a nested do can be used to
pass an intermediate value to the next operation:
foo2 x = do y ← do {x ′ ← x; f x ′ }
g y
The examples become increasingly inscrutable as more operations
are composed and multiple-parameter operations are used. Thus
rebinding the syntax of do does not provide a useful candidate for
a notation for programming with comonads.
7.2 Arrow notation
The arrow notation in Haskell provides a syntax for working with
abstraction notions of computation [5, 12]. Syntax for application,
abstraction (lambdas), and binding is provided abstracting over the
operations of some notion of computation defined as a category
with additional arrow operations for constructing computations
and extending environments. Arrow computations are defined by
a doubly-parametric data type (i.e. of kind ∗ → ∗ → ∗) and an
instance of the Category and Arrow classes:
class Category cat where
id :: cat a a
(◦) :: cat b c → cat a b → cat a c
class Category a ⇒ Arrow a where
arr :: (x → y) → a x y
first :: a b c → a (b, d) (c, d)
These operations are the minimal set of from which other arrow
combinators can be derived. A Category thus has a notion of
composition and identity for the morphisms, which are modelled
by the type cat x y. The Arrow class provides arr for promoting a
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 10 2012/9/22

Haskell function to a morphism of the category and first transforms
a morphism to take and return an extra parameter, which is used for
threading an environment through a computation.
Every comonad has an associated coKleisli category with morphisms
of structured input c a → b and the composition defined
in Section 2.1. All coKleisli categories are arrows where arr is
defined by pre-composing a function with current, and first is defined
similarly to the translation of binders threading an environment
through a computation in Section 3. The definitions are:
data CoKleisli c a b = CoK {unCoK :: (c a → b)}
instance Comonad c ⇒ Category (CoKleisli c) where
id = CoK current
(CoK g) ◦ (CoK f ) = CoK (g ◦ (cobind f ))
instance Comonad c ⇒ Arrow (CoKleisli c) where
arr k = CoK (k ◦ current)
first (CoK f ) = CoK (λx → (f (cmap fst x),
current (cmap snd x)))
The arrow notation comprises syntax for:
– abstraction proc x → e
– application f -< x
– binding x ← e
Thus, given the coKleisli instances for Category and Arrow,
comonadic operations can be written in the notation. For example,
consider the following codo-block for the array comonad:
codo a ⇒ b ← laplace1D a
c ← plus a b
d ← c ‘at‘ 1
if (current d > 1) then 1 else current d
This example uses both unary and binary operators, including at
which is a binary operator with one comonadic parameter and
one pure (i.e. non-comonadic) parameter, and includes a larger
expression that is not a simple function application.
This operation can be rewritten in the arrow syntax as:
proc a → b ← laplace1D ′ -< a
c ← plus ′
-< (a, b)
d ← (at ′ 1) -< c
CoK (λx → if (current x > 1) then 1
else current x) -< d
plus ′ = CoK (λx → plus (cmap fst x) (cmap snd x))
at ′ i = CoK (λx → x ‘at‘ i)
laplace1D ′ = CoK laplace1D
For unary function application the arrow notation is not much more
complicated than codo, requiring just the explicit application operator.
For multi-parameter operators e.g. a binary operator of type
c x → c y → z, the operator must be transformed to the type
c (x, y) → z e.g. plus ′ above, but the notation itself does not
become significantly more complex. For multi-parameter operators
with some pure parameters some transformation is needed such that
the pure parameters are passed first e.g. at ′ above. More complicated
expressions, that are not just the application of a function,
must be packaged into an operation first e.g. the conditional expression
above, which becomes more obfuscated.
Comparing the two approaches, the arrow notation appears to
be as powerful as the codo-notation in terms of the operations
which can be defined. However, whilst the arrow notation is almost
as simple as the codo-notation for some operations, there are
other operations where the syntax is much less natural. In general,
the codo-notation provides a more elegant, natural solution to programming
with comonads.
Data type Usage
c a = a × x (coreader, product) implicit parameters,
additional parameters e.g. dynamic programming
inputs
c a = x → a (exponent) numerical functions,
context-oblivious streams
c a = (x → a) × x (costate, in-context) streams, arrays,
general containers (for restricted x),
context-aware comonads
c a = [a ] (list) simple array-like comonad
c a = Array i a × i (cursored array) stencil computations,
dynamic programming
Figure 3. Summary of comonad examples in this paper
8. Further notations
We speculate that, since comonads abstract computations with
structured input then pattern matching, used for deconstructing a
data type often in the input of a function, may have special relation
to comonadic programming.
The authors’ previous work on a domain-specific language for
array computations has included a special pattern matching construction
for comonadic computations on arrays [11]. This pattern
matching syntax provides a partial pattern-match which is applied
at the current context of a cursored array. An example for the onedimensional
Laplace operator is:
laplace1D | x @y z | = x − 2 ∗ y + z
Here the pattern is delimetered by pipes | and consists of three
variable patterns where y is bound to the value at the current
context (cursor) i for the array, denoted by the @ symbol, x is
bound to the value at i − 1 and z is bound to i + 1. Thus the lexical
position of the remaining patterns, relative to the cursor pattern,
determines to which context they are bound. There can be only one
@ symbol for the whole pattern match.
This pattern matching syntax is used to provide static information
of the data access pattern on an array which is used in our DSL
to enforce safety properties on arrays at compile time and eliminate
run-time bounds checking [10].
A similar syntax could be imagined for other comonads. For example
streams could have a pattern syntax with @ for the current
position and with the ability to differentiate between the first position
in a stream and a position at any other point within the stream
e.g. followed by could be defined:
fby 〈@(x, y) | = x
fby | (x, y) @ | = y
In the first clause 〈 denotes the start of a stream thus at context 0
the first parameter is returned. The second clause matches context
n, returning the second parameter at context n−1 (where n >= 1).
We call this syntax context matching as it defines partial
matches focussed at the current context indicated by @. We speculate
that this syntax could be generalised to other comonads and
used to simplify definitions of comonadic operations.
9. Concluding remarks
Whilst monads are ubiquitous, comonads are still relatively underused
and less-widely accepted. A possible reason is that there are
fewer known useful comonads than of monads.
This asymmetry may be due to theoretical reasons. For example,
whilst there are many simple examples of monoids in mathematics
(+, ×, max, ∪, etc.) there are very few simple comonoids, in fact,
the trivial diagonal comonoid which duplicates its parameter appears
to be the only simple example. Since monads and comonads
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 11 2012/9/22

are respectively instances of monoids and comonoids in the category
of endofunctors the asymmetry between their examples may
have some effect at this higher-level. Whilst, monads have a productive
and generative flavour, creating and combining structured
data, comonads have a consuming or observational flavour which
is restricted. The shape preservation property (Section 4.1) shows
the restrictive nature of the comonad laws: an operation may only
observe a structure and transform the elements, but its shape must
be preserved. Compared with the ability of monads to create and
combine structure, comonads seem relatively constrained.
However, despite these reasons there are many useful comonads
of which this paper has shown several, summarised in Figure 3.
There are many more comonads which have not been shown including
examples on other recursive data types such as comonads
of trees [16] or graphs. The examples shown in this paper also have
variations. For example, the non-empty list comonad operated on
suffixes of a list but an alternate list comonad could provide operations
over the entire list with a cursor indicating the current element.
The cursor could be encoded as an address i.e. an integer
value of the current list position, or structurally by splitting the list
into the past, current, and future elements i.e. C a = [a ] a [a ].
It should be noted that many data types which are comonads
are instances of the general concept of containers [1]. Containers
have a set of shapes S, and for a particular shape s ∈ S there
�is
a set of positions P s. The general container data type is Fa =
s:S
(P s → a) i.e. a coproduct of maps from a set of positions to
values, for each possible shape. Ahman et. al recently showed that
this general formulation of containers is a comonad [2].
A shape preserving morphism on a container with a single shape
s is thus a morphism (P s → a) → (P s → b), which is equivalent
to a comonadic operation (P s → a) × P s → b) i.e. an operation
of the InContext comonad for P s contexts (the set of positions
for the s-shaped container). Lists, streams, trees, arrays, and graphs
fit within the container description – however using the InContext
comonad for these comonads may not be practical. For example the
Array data type for the array comonad provides a more efficient
implementation which is more easily mapped to hardware.
Whilst the codo-notation was developed here in Haskell, it
could be applied in other languages with further benefits. For example,
a codo-notation for ML could be used to abstract laziness using
a delayed-computation comonad with data type C a = () → a, or
defining lazy lists using the stream comonad shown here.
The simple and natural notation provided by codo presented
here considerably simplifies programming with comonads. It is our
hope that this prompts the use of comonads as a design pattern
and tool for abstraction and that it promotes further exploration of
comonads yielding new and interesting examples.
Acknowledgements
Thanks are due to Jeremy Gibbons, Tomas Petricek, Tarmo Uustalu,
and Varmo Vene for helpful discussions. This research was supported
by an EPSRC Doctoral Training Award.
References
[1] M. Abbott, T. Altenkirch, and N. Ghani. Containers: constructing
strictly positive types. Theoretical Computer Science, 342(1):3–27,
2005.
[2] D. Ahman, J. Chapman, and T. Uustalu. When is a container a
comonad? Foundations of Software Science and Computational Structures,
pages 74–88, 2012.
[3] E. A. Ashcroft, A. A. Faustini, R. Jagannathan, and W. W. Wadge.
Multidimensional programming. Oxford University Press, Oxford,
UK, 1995.
[4] S. Capobianco and T. Uustalu. A Categorical Outlook on Cellular
Automata. volume 13, pages 88–99, 2010.
[5] J. Hughes. Programming with arrows. Advanced Functional Programming,
pages 73–129, 2005.
[6] Richard B. Kieburtz. Codata and Comonads in Haskell, 1999.
[7] J. Lambek and P.J. Scott. Introduction to higher-order categorical
logic. Cambridge Univ Pr, 1988.
[8] Eugenio Moggi. Computational lambda-calculus and monads. In
Logic in Computer Science, 1989. LICS’89, pages 14–23. IEEE, 1989.
[9] Eugenio Moggi. Notions of computation and monads. Inf. Comput.,
93(1):55–92, 1991.
[10] D. Orchard and A. Mycroft. Efficient and Correct Stencil Computation
via Pattern Matching and Static Typing. Electronic Proceedings in
Theoretical Computer Science, 66:68–92, 2011.
[11] Dominic Orchard, Max Bolingbroke, and Alan Mycroft. Ypnos:
declarative, parallel structured grid programming. In DAMP ’10, pages
15–24, NY, USA, 2010. ACM.
[12] R. Paterson. A new notation for arrows. In ACM SIGPLAN Notices,
volume 36, pages 229–240. ACM, 2001.
[13] Tomas Petricek and Don Syme. Syntax Matters: writing abstract
computations in F#. Pre-proceedings of TFP, 2012.
[14] Dan Piponi. Evaluating cellular automata is comonadic, December
2006, Last retreived September 2009. http://blog.sigfpe.com/
2006/12/evaluating-cellular-automata-is.html.
[15] John Plaice. Cartesian Programming. University of Grenoble, France,
2010. HDR (Habilitation diriger des recherches).
[16] Tarmo Uustalu and Varmo Vene. Comonadic functional attribute
evaluation. Trends in Functional Programming-Volume 6, pages 145–
160, 2007.
[17] Tarmo Uustalu and Varmo Vene. Comonadic Notions of Computation.
Electron. Notes Theor. Comput. Sci., 203(5):263–284, 2008.
[18] Tarmo Uustalu and Varmo Vene. The Essence of Dataflow Programming.
Lecture Notes in Computer Science, 4164:135–167, Nov 2006.
[19] William W. Wadge and Edward A. Ashcroft. LUCID, the dataflow programming
language. Academic Press Professional, Inc., San Diego,
CA, USA, 1985.
[20] Philip Wadler. The essence of functional programming. In Proceedings
of POPL ’92, pages 1–14. ACM, 1992.
[21] Philip Wadler. Monads for functional programming. Advanced Functional
Programming, pages 24–52, 1995.
A. Proof of shape preservation
A useful additional derived property is that:
cmap g ◦ cobind f = cobind (g ◦ f ) (7)
The proof of which uses the definition of cmap (Section 2.1):
cmap f x = cobind (f ◦ current) x
cmap g ◦ cobind f
≡ cobind (g ◦ current) ◦ cobind f definition of cmap
≡ cobind (g ◦ current ◦ cobind f ) [C3]
≡ cobind (g ◦ f ) � [C2]
Secondly, const has the property that: (const x)◦f = (const x)◦
g. The proof of shape preservation is then:
shape ◦ (cobind f )
= (cmap (const ()) ◦ (cobind f ) definition of shape
= cobind ((const ()) ◦ f ) (7)
= cobind ((const ()) ◦ current) const property
= (cmap (const ())) ◦ (cobind current) (7)
= cmap (const ()) [C2]
= shape � definition of shape
Draft- Long version - Short version appears in pre-proceedings of IFL 2012 - Last updated September 22, 2012 12 2012/9/22