Monadic Dynamical Systems in C++ with Concepts and in Haskell

Monadic Dynamical Systems
in C++ with Concepts and in Haskell
Daniel Lincke 1,∗ , Patrik Jansson b , Marcin Zalewski c , Cezar Ionescu 1
a Potsdam Institute for Climate Impact Research, Potsdam, Germany.
b Chalmers University of Technology & University of Gothenburg, Gothenburg, Sweden.
c Indiana University, Bloomington, USA.
Abstract
In scientific programming, the implementation of a computational model goes hand in
hand with a deep analysis of the underlying domain. Software developers and domain
experts work together to develop a common understanding and a (possibly executable)
specification. Such a specification should be easy to understand and serve as a sketch
for an implementation in a high-performance language. In this paper, we describe
a domain using Haskell as a modelling language and then we derive a generic implementation
framework from the Haskell model. To achieve this, we transform functional
Haskell constructs describing the domain notions into a hierarchy of concepts, generic
algorithms, and generic constructors. Our approach is flexible: we can implement a library
based on these concepts in every language which supports concept-based generic
programming.
In particular, we begin with the domain of vulnerability assessment. We start with
analysis of the domain, and we provide a high-level executable model based on dynamical
monadic systems. Then we systematically translate the model into a generic
concept-based library. Our approach is demonstrated by a translation into C++, but also
sketch how to reimplement our library in Haskell using the same principles.
Keywords: generic programming, functional programming, vulnerability assessment
1. Introduction
The road from a domain of scientific knowledge to an efficient implementation
is long and perilous, often resulting in an implementation that bears little apparent
resemblance to the domain. Still, the practitioners of high-performance computing are
willing to pay the price of overwhelmingly low-level implementations to guarantee
performance. In the current day and age, however, it is possible to increase the level of
abstraction by applying generic programming techniques to provide a high-level library
∗ Corresponding author
Email addresses: daniel.lincke@pik-potsdam.de (Daniel Lincke), patrikj@chalmers.se (Patrik
Jansson), zalewski@osl.iu.edu (Marcin Zalewski), ionescu@pik-potsdam.de (Cezar Ionescu)
Preprint submitted to Science of Computer Programming March 1, 2011

for a domain that allows structured use of existing, efficient code. In this paper, in
particular, we show how to first describe a domain in a high-level functional style, close
to mathematical notation but executable, and, then, transform this description into a
strongly generic library that corresponds closely to the initial description. Specifically,
we present the process by which we derived a generic C++ (Stroustrup, 1997) library
for vulnerability assessment (vulnerability in the context of environmental sciences).
The concept of “vulnerability” plays an important role in many research fields, including
climate change research (Adger, 2006). As we discuss in Sect. 2, there is no
unique definition of this term. However, there is a simple common structure underlying
the definitions in the usage of “vulnerability”, which can be shortly described as measuring
the possible harm for a given system. Systems may be of very different natures,
but it turns out that the differences can be captured by the idea of monadic dynamical
systems that hides the particulars of a system behind a curtain of abstraction.
Our C++ library for monadic systems is derived from the high-level description in
Haskell (Peyton Jones, 2003), given by Ionescu (2009) in his formalisation of vulnerability
done at the Potsdam Institute for Climate Impact Research. Ionescu relies on
functional features of Haskell, such as function types and type constructors, to represent
the underlying mathematical notions of, among others, functors, coalgebras, monads,
and, crucially, of monadic dynamical systems, which we introduce and explain in
Sect. 2.3. While his description can be executed, its design is focused on exposition of
ideas and not on efficiency. Furthermore, the description is not generic enough to be
applied in a practical setting of existing implementations, tool sets, and so on.
Our library maintains the abstract, high-level correspondence with the domain notions
introduced by Ionescu but it makes efficient implementations possible by providing
a generic interface for use of high-performance components. We are able to achieve
the abstraction by basing the libraries on concepts, a well known term in generic programming.
A concept is an abstract specification of a set of (tuples of) types (Bernardy
et al., 2010). While in Haskell concepts are provided by means of type classes (Wadler
and Blott, 1989), in C++ they are still an experimental language feature called C++concepts
(Gregor et al., 2006, 2008c). We use concepts to specify three kinds of components
from our application domain:
• a conceptual framework specifying concepts for functional constructs, like functions,
functors, monads, and so on;
• parameterised types, themselves “typed” by concepts, that represent domain constructs
and combinators;
• and, finally, generic functions representing the algorithms applicable in a given
domain.
These components provide a generic, algorithmic description of a domain. The user
of our library must then plug in his/her complex data structures, but that is done only
once for each concept, rather than for any possible combination required by every
combinator or algorithm. As an alternative, we provide some simple data structures
that are meant for Haskell-like prototyping rather than a full-blown implementation.
2

Functions
Function Fun ∼ a -> b : describes general unary function types
Type Constructors
ConstructorType T ∼ f :: *->* : the type T is a unary type constructor
SameTypeConstructor
T1 ∼ f :: *->*, T2 ∼ f :: *->* : two types represent the same
type constructor
Functors and Monads
Functor
the type T is a unary functor type
: ConstructorType
Monad
the type T is a unary monad type
: ConstructorType
Figure 1: Overview of the core concepts of the functional C++ concepts library. The full library also contains
concepts like FunctionN and FunctorN (for small N) and related convenience functions.
Constructors for Monadic system
Discrete_Monadic_System
Trans ∼ (x -> m x) : a discrete monadic system
∼ Int -> (x -> m x)
is constructed from a given transition function Trans
Monadic_System_Input
Trans ∼ i -> (x -> m x), Cont ∼ [i] : an MDS
∼ [i] -> (x -> m x)
with input of type [i] is constructed from a given
transition function Trans
Combinators for Monadic system
Monadic_Systems_Parallel
∼ (i1, i2)-> ((x,y)-> PairM m n (x,y))
Sys_Ser_Function
∼ (i1, i2)-> x -> m x
Sys1 ∼ i1 -> (x -> m x),
Sys2 ∼ i2 -> (y -> n y): : Two monadic systems
are combined in parallel
Sys1 ∼ i1 -> (x -> m x),
Sys2 ∼ i2 -> (x -> m x) : two monadic systems
with the same state space and the same monad are
combined into a combined transition function with
input
Figure 2: Overview of the main parametrised types in the library
Special Function types
Coalgebra Fun ∼ x -> f x : functions whose codomain is a functor
: Function
application
CoalgebraWithInput Fun ∼ i -> x -> f x : coalgebras with an additional
: Function2
input
MonadicCoalgebra Fun ∼ x -> m x : functions whose codomain is a monad
: Coalgebra
application
MonadicCoalgebraWithInput Fun ∼ i -> x -> m x : monadic coalgebras with an
: CoalgebraWithInput additional input
Monadic system
MonadicSystem
: Function
Sys ∼ i -> (x -> m x) : Sys is a monadic system
Figure 3: Overview of the main concepts in the Monadic systems library
The library for monadic dynamical systems presented in this paper consists of two
parts. First, we capture the basic constructs of functional programming in a separate
library called FCPPC (Functional C++ with Concepts) (Lincke, 2010; Lincke and
Schupp, 2009). In contrast to other existing libraries for functional C++ programming,
like FC++ (McNamara and Smaragdakis, 2004a), our intention is not to provide the
3

whole Haskell prelude in C++. We rather provide a framework of concepts which specifies
types for functional constructs. This library is independent of the vulnerability
domain, and can, or even should, be reused when our approach is used in other domains.
Next, using the FCPPC library as the base, we capture the constructs from the
domain of monadic dynamical systems. While our library is split into two parts based
on reusability of the components of each part, both parts are derived using the same
approach and both parts consists of the three kinds of components described before.
In order to give an overview of our approach, the core concepts from FCPPC are
outlined in Fig. 1 and the core concepts and constructors/combinators of the monadic
systems library are presented in Fig. 3 and Fig. 2. In both figures the left column shows
the signature of the concepts and functions as well as refinement relations, written in
C++ syntax. The right column shows how the parameters of the concept match the
Haskell signature (we write C ∼ t for “C++ type C corresponds to Haskell type t”).
Furthermore we give a brief explanation of what the concept or function is intended
to model. The concepts are divided into groups for presentation reasons (the grouping
does not imply any hierarchy). In Figs. 1 and 3 we do not intend to give a detailed
description of the concepts we use, therefore associated entities are not stated.
A library like our monadic system library is much more complex and verbose than
its high-level specification in Haskell but it is surprisingly similar and nimble from
the point of view of the user. For example, the computation of macro-trajectories (see
Sect. 2.3) is cleanly specified in Haskell as a function of the following type:
1 macro_trj :: (Monad m) => (i -> x -> m x) -> x -> [i] -> [m x]
In the C++ library functional constructs are lifted to the concept level, and the type of
the function has to be translated accordingly (expressing sequences with C++’s iterator
mechanism):
1 template
3 requires
4 std::SameType,
5 std::SameType
6 void
7 macro_trajectory(Mon_Sys sys,
8 Inp_Iter controls_bg, Inp_Iter controls_end,
9 Mon_Sys::Codomain::Domain1 x,
10 Out_Iter& ret);
In C++, the type of the Haskell macro_trj function must be expressed in terms of
concepts. Besides the concept MonadicSystem that is taken form our library, we rely
on concepts from the C++ standard library (preceded by the std:: prefix). While a
function like macro_trajectory clearly is more complex from the point of view of a
library developer, the complexity is hidden when the function is used:
1 macro_trajectory(my_sys, ctrl.begin(), ctrl.end(), init, ret);
The user must declare the necessary modellings (called “concept maps” in C++ and
“instances” in Haskell) that describe how types model the necessary concepts. The decoupling
of concepts and their modellings makes it possible to use the library with the
existing high-performance implementations while keeping the complexity manageable.
4

This paper is based on an earlier conference paper (Lincke et al., 2009). We generalised
the approach by separating the functional components out into a separate library.
Furthermore we made the approach more widely applicable by transforming the functional
constructs and the domain notions into concepts in general. With these general
concepts it is possible to implement the resulting library in any language which provides
an implementation of concepts. From the point of view from the library, we
additionally explored questions of system combination and present some useful combinators
for monadic dynamical systems.
In the remainder of the paper, we outline the progression from the domain to an
efficient implementation by first expressing domain notions in a functional form, and
then implementing them using our library of functional concepts, This is illustrated by
our particular path from the domain of monadic systems in the context of vulnerability
assessment to our C++ library for monadic systems. In Sect. 2, we present the concept
of vulnerability as used in the climate change community and its mathematical formalisation
in Haskell. We show that different kinds of dynamical systems are involved in
vulnerability studies and explain why monadic dynamical systems are an appropriate
model for these systems. Sect. 3.1 shows how functional constructs like functions,
functors and monads can be expressed by concepts and show a C++ implementation of
them. Sect. 3.2 describes how the domain specific constructs (concepts, parametrised
types and functions) of the monadic systems domain are provided in C++ and Sect. 3.3
shows how the library can be used. Sect. 4 explains how the concepts can be implemented
using type classes in Haskell. In Sect. 5 we survey related work and in Sect. 6
we discuss our approach and present ideas how to further generalise it.
1.1. Preliminaries
We use Haskell code for describing the mathematical model, concepts for describing
the conceptual framework and C++ code for describing the actual implementation.
Here we give a very short description of some of the notation used. It is worth noting
already from the start that :: is used in two different ways: in Haskell it is the “has
type” keyword, while in C++ it is the “scope resolution” operator.
1.1.1. Functional modelling
Any pure functional language with appropriate support of generic programming
could be used for our mathematical modelling of monadic dynamical systems. Such
languages usually have clean syntax and stay close to the original mathematical notation
from which they borrow their expressive type systems and algebraic type classes.
We picked Haskell (Peyton Jones, 2003), without any of the language extensions, for
specification of the mathematical model. As usual in Haskell we denote function application
by juxtaposition: f a denotes the application of f to a, parentheses are not
needed. Function composition is (.) :: (b ->c) -> (a -> b) -> (a -> c) and for
Kleisli composition we use ( (a -> m b) -> (a -> m c)
We use two recursion operators for lists—foldr and scanr—which are best introduced
by example. If we define sum = foldr (+) 0 and sums = scanr (+) 0 then
sum [3,2,1] is 6 and sums [3,2,1] are the partial sums [6,3,1,0]. Following a similar
pattern we use foldr to compose lists of monadic actions:
5

1 mcompose :: Monad m => [x -> m x] -> (x -> m x)
2 mcompose = foldr ( [a] which creates a list by repetition
of a given element. For testing we write predicates (parametrised test cases) as
normal Haskell functions run by QuickCheck (Claessen and Hughes, 2000). Finally we
use the type constructor SimpleProb for probability distributions with finite support.
1 type Prob = Double
2 newtype SimpleProb a = SP [(a, Prob)] deriving Show
The Haskell type system is complex enough to have has its own type system: kinds.
Base types, like Bool, are of kind * while a parametrised type like SimpleProb has kind
*->*.
1.1.2. Concepts
For concepts we stick to the terminology from (Bernardy et al., 2010; Garcia et al.,
2007a). We use the term concept for an abstract specification of a set of (tuples of)
types, where the arity of a concept is the size of the tuple (the number of type parameters).
Semantically, a concept is a predicate over types. When a tuple of types satisfies
this predicate, we say that it is a model for the concept. A concept has a number of
associated entities (often called members): values, functions, or types. Definitions for
these entities are provided in the modellings (model declarations). In addition, a concept
can state requirements for its types. Modellings are type-checked taking these
requirements into account. Concepts can refine each other. A concept C 1 refines another
concept C 2 if C 1 implies C 2 , that means the associated entities of C 2 are available
whenever the entities of C 1 are available. In this paper we describe concepts literally
by listing their associated entities.
1.1.3. Concepts in C++
C++ implements concepts by the experimental language feature C++-concepts
(Gregor et al., 2006, 2008c). Concepts can be used to constrain the type parameters
of templates using the requires keyword. Templates (basically pieces of code
parametrised by types or values) are the generic programming technique of C++. Concept
modelling in C++ is done by concept maps which are used to bind names dependent
on type parameters to the implementations provided by the user (Gregor et al., 2006,
2008c).
The following snippet of code is a complete example of using concepts:
1 concept Function {
2 typename Domain1;
3 typename Codomain;
4
5 Codomain operator () (Fun, Domain1);
6 };
7
8 template
9 requires
10 Function,
6

11 std::SameType
12 Fun::Codomain twice(Fun fun, Fun::Domain1 x) {
13 return fun(fun(x));
14 }
15
16 struct Increment {
17 typedef Int Domain1;
18 typedef Int Codomain;
19
20 Codomain operator()(Domain1 x) { return x++; }
21 };
22
23 concept_map Function {
24 typedef Increment::Domain1 Domain1;
25 typedef Increment::Codomain Codomain;
26 }
27
28 Increment inc;
29 int x = twice(inc,0);
The concept Function, defined from Line 1, defines a predicate on a single type and
requires two associated type Domain1 and Codomain and an application operator ().
Thus, the concept specifies function types. It is then used, on Line 10, to constrain the
sole type parameter of the twice function. The requirement ensures, that the parameter
type is a function type. The second requirement (Line 11) states that this function
type is a homogeneous function, which makes it possible to apply the function two
times. The user-defined type Increment, defined in Lines 16–21, is than declared to
model Function, on Line 23. In the model declaration the bindings for the associated
types are provided (Lines 24–25) while the definition of the associated operator is
not given explicitly. In such situations, the compiler is required to attempt to find a
matching definition in the context, and, in this case, it finds the application operator
of Increment. Finally, the usage of concept-constrained twice is demonstrated on
Line 29: the application twice(inc,0) concept-checks, since the required concept
map has been defined.
While in the above example, requirements on the twice function were all given
in the requires clause, concepts can be also written “inline.” Thus, the Function
requirement from could be also written as:
template
We use the inline notation frequently as it signifies the “types of types” role of concepts.
As concepts are an experimental feature they are not supported by common compilers.
To make the C++ code compilable on standard compilers we use traits (Myers,
1995) to simulate concepts. Traits are template classes which provide bindings for associated
entities by specialisations for particular types, without being able to check the
type correctness of templates.
The C++ code in this paper is tested with the gcc compiler 1 , version 4.3, and the
1 http://gcc.gnu.org/
7

concept code is partly tested with the ConceptGCC compiler 2 (version alpha 7). In
C++, we name concepts in CamelCase, and for class names we use Camel_Case with
underscores. Furthermore, in the C++ code we usually omit unnecessary details such as
const qualifiers or reference (&) type modifiers—while these are important for performance
they do not contribute to the exposition. Finally, in template parameter lists, the
keywords class and typename are freely exchangeable—the variations in the paper are
motivated by space constraints.
1.1.4. Haskell with concepts
Concepts are implemented in Haskell by the means of type classes (Wadler and
Blott, 1989). Models of concepts are declared by the instance declaration keyword,
constraining an algorithm with concept requirements is done with the => declaration.
We make frequent use of the concepts Monad with members functions (>>=) (pronounced
“bind”) and return and the Functor concept with the member function fmap.
1 class Functor f where
2 fmap :: (a -> b) -> f a -> f b
3
4 class Monad m where
5 (>>=) :: m a -> (a -> m b) -> m b
6 return :: a -> m a
Note that the parameters f and m are of kind * ->*, so these concepts (type classes)
constrain type constructors, not types. Type classes with parameter of other kind than
* are sometimes called constructor classes (Jones, 1993).
The list type constructor [] is a model of both the Functor and the Monad concept:
1 instance Functor [] where
2 fmap = map
3
4 instance Monad [] where
5 xs >>= f = concat (map f xs)
6 return x = [x]
Over the years Haskell has acquired a number of extensions (for multiple parameters,
associated types, equality constraints, etc.) to the basic idea of type classes and in
Sect. 4 we use quite a few of those extensions to port the C++ conceptual framework
for monadic dynamical systems “back to Haskell”.
2. Vulnerability Modelling
In the past decade, the concept of “vulnerability” has played an important role in
fields such as climate change, food security, and natural hazard studies. Vulnerability
studies have been useful in alerting policymakers to the possibility of precarious
situations in the future.
2 http://www.generic-programming.org/software/ConceptGCC/
8

However, definitions of vulnerability vary: there seem to be almost as many definitions
of vulnerability as case studies conducted. Wolf et al. (2008), for instance,
analyse the usage of 20 definitions of vulnerability. An allegory frequently used to
describe the terminology is the Babylonian confusion, and the need for a common understanding
has repeatedly been expressed in the literature (Brooks, 2003; Janssen and
Ostrom, 2006).
While definitions of vulnerability are usually imprecise, Ionescu (2009) proposes
a mathematically defined framework that underlies the definitions and the usage of the
term vulnerability. Ionescu’s framework applies to those studies that “project future
conditions” by using computational tools and that can thus be designated as computational
vulnerability assessment. This common framework for vulnerability assessment
consists of three primitive concepts: an entity (which is subject to possible future
harm), possible future evolutions (of the entity), and harm. Next, we briefly summarise
Ionescu’s development. First, we discuss the primitive concepts and, then, their extension
to monadic dynamical systems.
2.1. A Simple Mathematical Model of Vulnerability
An entity, its current situation, and its environment are described by a state. In
vulnerability computations, the current state of an entity is only a starting point; it is the
evolution of the state over time that is the main focus of interest. A single evolution path
of an entity is called a trajectory. In a first, simple vulnerability model, the evolution
of an entity is computed in a single step:
1 possible :: State -> F Evolution
The possible function maps a state into an F-structure of future evolutions. Two
types and one type constructor are involved: State is the type of the state of an entity,
Evolution is the type of the evolution of an entity, and F is the type constructor
representing the structure of evolutions (e.g., a set). In this simple model we take
Evolution = [State]: an evolution is a finite sequence of the states that an entity
successively assumes over time. This notion is sufficient, as most vulnerability assessments
are made for a given horizon, which is expressible as a finite evolution.
The constructor F is a functor (see Sect. 1.1) that describes the nature of the future
computation. For example, if the future of an entity is deterministic, one would
have F = Id, the identity functor, giving a single evolution. Sometimes, a more sophisticated
model may be necessary. For instance, a stochastic model might be used,
which computes probability distributions over trajectories; the stochastic functor introduced
in Sect. 1.1 captures such situations (F = SimpleProb). Some other models
might produce just lists of trajectories, without assigning a specific probability to each
possibility. For these models, the trajectories are enclosed in the list functor (F = []).
The second ingredient of a vulnerability computation is a harm judgement function:
1 harm :: Evolution -> Harm
The harm function maps evolutions into values of type Harm, which describes the nature
of the harm assessment. One of the simplest harm assessments is a threshold measurement.
Examples of thresholds that can be crossed include temperature that grows too
9

high or a budget that is too low. Correspondingly, threshold harm measurement judges
two possibilities, namely “yes, there is harm for this evolution” or “no, there isn’t any
harm when the entity evolves in this way.” In such cases, harm is simply a boolean
value (Harm = Bool). In other models, the harm value for each trajectory may be measured
as a real value (Harm = R). A more sophisticated model might measure multiple
dimensions of harm, all expressed as real values, which would lead to Harm = R N .
The harm function measures the harm of a single evolution, but a model produces
an F-structure of evolutions, given some implementation of the function possible. The
harm function must then be mapped to the evolutions, using the fmap function of the
functor F (see Sect. 1.1). A measure function takes the resulting F-structure of harm
values and summarises them into an overall measurement:
1 measure :: F Harm -> V
The codomain of the measure function could be, for example, the real numbers (to get
the result as a single number, a way of expression policymakers prefer) or a multidimensional
space (to express various dimensions of vulnerability instead of collapsing
it into a single number). Common examples for the measure function are measure
= maximum in the case of F = [] and Harm = Bool, or measure = expectation in the
case of F = SimpleProb and Harm = R.
Combining these three functions gives the vulnerability computation:
1 vulnerability :: State -> V
2 vulnerability = measure . fmap harm . possible
This computation captures the idea behind many vulnerability definitions: we measure
the harm that might be possible. The following example illustrates the use of the
vulnerability computation framework:
1 type Economy_State = (Double, Double, Double, ...)
2 -- GDP, GDP-growth, Unemployment Rate, and so on ...
3 type Economy_Evolution = [Economy_State]
4
5 possible_economy :: Economy_State -> [ Economy_Evolution ]
6 possible_economy x = -- ... implement a model of an economy here
7
8 economic_harm :: Economy_Evolution -> Double
9 economic_harm ec_ev = -- ... return -(biggest GDP-change)
10
11 economic_vulnerability :: Economy_State -> Double
12 economic_vulnerability = maximum . fmap economic_harm . possible_economy
The implementation of the economy evolution function is unspecified, but the type
indicates that it is performed non-deterministically. Harm is defined as the greatest
decrease in Gross Domestic Product (GDP) over a trajectory; the harm function returns
zero if the GDP is always increasing. In the final vulnerability computation, the
maximum function is used as measure, defining vulnerability as the greatest economic
loss over all possible evolutions of the economy from a given state.
10

2.2. Vulnerability measures
An important result of this analysis, going beyond the implementation of software
components, is the increased understanding of vulnerability. This is often the case with
developing a Domain Specific Language (DSL): the activity leads to a deeper understanding
of the domain, not just for the computer scientist, but even for the domain
expert. We give here a couple of examples.
We were able to formulate precisely the natural condition of consistency between
the impact evaluations and the vulnerability measure: if the harm in the structure increases,
then the vulnerability measure should not decrease. This can be formalised
as follows: for any function f :: Harm -> Harm with h V and m2 :: F2 Harm -> V are
said to be compatible with respect to tau if, for all hs1, hs2 :: F1 Harm we have
that m1 hs1

2.3. Monadic Systems and Vulnerability
The simple model of vulnerability presented in the previous section has two main
disadvantages. First, it is not very generic: as shown in the economy example we have
to write a new function for every vulnerability computation. This can easily be fixed by
making possible, harm and measure inputs to the vulnerability computation. Second,
the model is inflexible: the evolution function of the simple model only consumes the
initial state of a system as the input. In practise, however, an evolution function often
has more inputs. In particular, an evolution may depend on auxiliary control arguments
that are not part of the initial state of a system.
Ionescu (2009) explores possible structures which might provide the required flexibility.
On the one hand the multitude of systems which might be involved has to be
represented, on the other hand we want an easy way of computing iterations. It turns
out that a functorial structure on the possible evolutions is not suitable for the trajectory
computations and that the use of a monad instead of a functor gives the possibility
to iterate a system. Therefore, the notion of a monadic dynamical system (MDS) was
introduced. In contrast to the possible function, trajectories of a model defined by
an MDS can be computed in multiple separate steps. For example, a trajectory of an
MDS can be computed up to a certain point, the result archived, and the computation
continued later with this intermediate result as a starting point.
An MDS is a mapping with the signature t -> (x -> m x), where m is a monad
(see Sect. 1.1). An MDS takes a value of type t (e.g., t = Nat) to a (monadic) transition
function of type x -> m x. Every MDS must fulfil some further conditions; for
instance, the type t has to form a monoid structure (with a zero z and an operation
(+.)) and the MDS must preserve that structure (must be a monoid morphism). More
precisely, the following two laws (expressed as predicates) have to be satisfied (where
(=.=) is pointwise equality for functions):
1 sys_law_zero sys = sys z =.= return
2 sys_law_plus sys t1 t2 = sys (t1 +. t2) =.= (sys t2 [Int]
2 my_discrete_trans x = [x-1, x+1]
We can construct an MDS from my_discrete_trans using discrete_sys:
1 type Nat = Int
2 discrete_sys :: (Monad m) => (x -> m x) -> (Nat -> x -> m x)
3 discrete_sys f n = mcompose (replicate n f)
Not all transitions of interest are that simple. Often, a transition function does
not only map a state into an M-structure of states, but also takes an additional control
parameter. This parameter describes some external input which is not a part of the
12

state. Such a function describes a family of transition functions, one for each control
input. Consider the following example:
1 type MyControl = Double
2 type MyState = Double
3 my_input_trans :: MyControl -> (MyState -> SimpleProb MyState)
4 my_input_trans delta x = SP [(x + delta, 0.75),
5 (x - delta, 0.25)]
Here, every input delta gives a different transition function. The function itself is not
an MDS (because it fails to satisfy the MDS laws). But it can be used to construct a
monadic system by using the following constructor:
1 input_system :: (Monad m) => (i -> x -> m x) -> ([i] -> x -> m x)
2 input_system trans = mcompose . map trans
Furthermore, given an MDS, two iteration functions can be defined: the macro
trajectory function, macro_trj, computes the evolution of an M-structure of states, and
the micro trajectory, micro_trj, computes the M-structure of evolutions (sequences of
states). Both computations start with a sequence of inputs of type i and an initial state.
The macro trajectory describes all possible states at each step of the computation, but
does not connect them:
1 macro_trj :: (Monad m) => (i -> (x -> m x)) -> [i] -> x -> [m x]
2 macro_trj sys ts x = scanr (\i mx -> mx >>= sys i) (return x) ts
The micro trajectory records the single evolution paths including all intermediate states:
1 micro_trj :: (Monad m) => (i -> (x -> m x)) -> [i] -> x -> m [x]
2 micro_trj sys is x = mcompose (map (addHist . sys) is) [x]
3
4 addHist :: (Monad f) => (x -> f x) -> [x] -> f [x]
5 addHist g (x : xs) = liftM (:(x : xs)) (g x)
Computing the trajectories for the MDS constructed out of my_discrete_trans from
the initial state myx = 0 and the input sequence myts = [1,1,1] yields:
1 macro_trj (discrete_sys my_discrete_trans) myts myx ==
2 [ [-3,-1,-1,1,-1,1,1,3],
3 [-2,0,0,2],
4 [-1,1],
5 [0]]
6
7 micro_trj (discrete_sys my_discrete_trans) myts myx ==
8 [ [-3,-2,-1, 0], [-1,-2,-1, 0], [-1, 0,-1, 0], [ 1, 0,-1, 0],
9 [-1, 0, 1, 0], [ 1, 0, 1, 0], [ 1, 2, 1, 0], [ 3, 2, 1, 0]
10 ]
The example clarifies the nature of the two trajectory computations: The macro trajectory
provides the information that the state of this system is 0 at the beginning. After
one step the state is either -1 or 1, after two steps it can be in state -2, 0 or 2 and so
on. The micro trajectory function returns all the individual trajectories the system can
take, from [-3,-2-1,0], where we always take the -1 path, to [3,2,1,0]. Macro and
micro trajectories are, as shown by Ionescu (2009), related by:
13

1 fmap (!!n) (micro_trj sys ts x) == (macro_trj sys ts x !! n)
It should be noted that while the trajectory computations work for any monadic coalgebra
with input, these laws are only valid for monadic dynamical systems (Ionescu,
2009). Note furthermore, that the computed states are prepended to the list, leading to
the unintuitive ordering of states with the final state at the head of the list. The input of
myts are processed in the same order: starting from the end of the list and proceeding
to the first element.
Many computational models used in the climate change community already implicitly
implement the structure of an MDS. For instance, the climate model CLIMBER
(Petoukhov et al., 2000) has an internal state which represents the current configuration
of certain physical parameters. In addition, CLIMBER takes as an input the concentration
of greenhouse gases. The CLIMBER model can be described as an MDS built from
a family of transition functions with signature climber :: GHG -> (Climber_st ->
F Climber_st), where GHG is the type of values representing concentration of greenhouse
gases, and F = Id is the identity monad, since CLIMBER is deterministic.
To tie back to vulnerability assessment, the micro_trj computation for an MDS
fits the signature of the possible function in a vulnerability computation. Thus, the
possible can be computed as the structure of micro-trajectories of an MDS. Taking
this into account we can compute vulnerability as:
1 vulnerability’ :: (Functor m, Monad m) =>
2 (i -> x -> m x) -> ([x] -> h) ->
3 (m h -> v) -> [i] -> x -> v
4 vulnerability’ sys harm measure ts = measure . fmap harm . micro_trj sys ts
Using the above definitions, the examples of the possible functions from the previous
section, with F = Id, F = [], or F = SimpleProb as the resulting structures, can all be
easily translated to an MDS, since all these functors are also monads.
2.4. Combining monadic dynamical systems
One monadic system is rarely used alone, at least in vulnerability assessment. It
is, in fact, a common task to build a model of a complex system, such as the climate
system, from building blocks: a model of the atmosphere, a model of the ocean, one
for the ice-sheets at the poles, and so on. There are problems that are characteristic for
the type of modelling needed in vulnerability studies. In particular the building blocks
are often represented in very different ways: physical systems might be described by
deterministic or stochastic systems, while the social systems are usually described as
non-deterministic or fuzzy. Even if all the systems operate on the same time scale,
even if the geographical resolution is identical and all shared variables have uniform
semantics, it is still not clear how to compute the trajectory of a combination of, say,
deterministic and non-deterministic systems.
Unfortunately, there is no unique way of combining monads to yield monads (King
and Wadler, 1992). The same two monads may be combined differently, yielding different
results. Accordingly, we present those combinations of systems which are most
likely to be useful in the practice of computational vulnerability assessment.
14

The simplest way of combining two systems is to put them in parallel. The trajectories
of the two systems are computed independently, and are combined by tupling.
Thus, given two systems sys1 :: t1 -> x -> m x and sys2 :: t2 -> y ->
n y, putting them in parallel results in the system syspar (sys1, sys2) :: (t1, t2)
-> (x, y) -> (m x, n y). It is trivial to check that syspar (sys1, sys2) is a monoid
morphism (given that sys1 and sys2 are monoid morphisms).
However, syspar (sys1, sys2) cannot be made a monadic dynamical system in
Haskell, because of the fact that there is no possibility to declare (M, N) to be a monad
as the notion (M, N) does not even type check. In order to circumvent this problem
we provide a technical workaround which starts with defining the “pairing” of two
monads:
1 newtype PairM m n a = PM (m a, n a)
2 unwrapPM :: PairM m n a -> (m a, n a)
3 unwrapPM (PM x) = x
4
5 instance (Monad m, Monad n) => Monad (PairM m n) where
6 return x = PM (return x , return x )
7 (PM (mx, nx)) >>= f = PM (mx0, nx0)
8 where
9 mx0 = mx >>= (fst . unwrapPM . f )
10 nx0 = nx >>= (snd . unwrapPM . f )
11
12 pr :: Functor f => (f a, b) -> f (a, b)
13 pr (fa, b) = fmap (\a -> (a, b)) fa
14
15 pl :: Functor f => (b, f a) -> f (b, a)
16 pl (b, fa) = fmap (\a -> (b, a)) fa
17
18 syspar :: (Functor m, Functor n) =>
19 (t1 -> x -> m x , t2 -> y -> n y) ->
20 (t1, t2) -> ((x, y) -> PairM m n (x, y))
21 syspar (sys1, sys2) (t1, t2) (x, y) = PM (pr (sys1 t1 x, y),
22 pl ( x, sys2 t2 y))
Even if the definition of syspar only requires the functoriality of m and n, further conditions
are needed for syspar (sys1, sys2) to also be a monoid morphism, therefore
a monadic system. (More precisely, m and n need to be monads and sys1 and sys2
monoid morphisms.)
System combination becomes more complicated when the involved systems interact
(something they cannot do when combined in parallel). In the following we only
consider interaction through shared state: the two systems are assumed to have the
same state space X, although possibly different monoids and monads. This represents
the following situation: an initial state (element of X) is modified by the first system
according to an input from its own monoid, the resulting macro-state is then modified
by the second system according to an input from its monoid, and so on. If both systems
have the same monad, that is sys1 :: t1 -> x -> m x and sys2 :: t2 -> x ->
m x, one could expect the serial combination to be defined as: comb (sys1, sys2)
(t1, t2) = (sys2 t2)

Ionescu (2009) for explanation). Rather, we can define a system combination sysser
which uses pairs (t1, t2) as inputs:
1 sysser :: (Monad m) => (t1 -> x -> m x,
2 t2 -> x -> m x) ->
3 [(t1, t2)] -> x -> m x
4 sysser (sys1, sys2) = input_system f
5 where f (t1, t2) = sys2 t2 (t1 -> x -> Id x,
2 t2 -> x -> m x) ->
3 [(t1, t2)]-> x -> m x
4 detserl (detsys, sys) = sysser (embedMDS detsys, sys)
5
6 detserr :: (Monad m) => (t1 -> x -> m x,
7 t2 -> x -> Id x) ->
8 [(t1, t2)]-> x -> m x
9 detserr (sys, detsys) = sysser (sys, embedMDS detsys)
10
11 embedMDS :: (Monad m) => (t -> a1 -> Id a) -> t -> a1 -> m a
12 embedMDS detsys t = return . unwrapId . detsys t
If there is no deterministic system involved, serial combination becomes more difficult.
This case is beyond the scope of this paper, we refer to Ionescu (2009) for discussion.
3. Vulnerability Modelling in C++ with Concepts
In the previous section, we used Haskell to describe monadic systems and vulnerability
assessment at high level, more in the mathematical specification style than as a
practical computational library. Thanks to its laziness and its clean notation, Haskell
serves well as a modelling and prototyping language that enables one to write operational
definitions that can be executed.
However, an executable specification such as the one we have given in the previous
section is not practical in real-life scientific programming. High-performance
computing is usually performed in very specific and complex environments, and often
there are many existing libraries and code bases that must be integrated. In this section
we present a C++ library for monadic dynamical systems that addresses the shortcomings
of the high-level Haskell description while maintaining much of the description’s
clarity and structure. We choose C++ because of its support of high-level generic programming,
the ease with which existing components can be integrated, and because
C++ is well supported on high-performance platforms.
Our choice of C++ is not a crucial decision. By expressing the high-level structure of
functional constructs in a generic manner by specifying their requirements as concepts,
16

our library is implementable in every language that provides support for generic programming
with concepts. While we rely on the C++ concepts (discussed in Sect. 1.1.3)
to capture the notions of the domain, a recent study by Garcia et al. shows that there are
other languages with an appropriate generic programming support. In section Sect. 4
we sketch how a similar concept-based library can be constructed in Haskell.
Our methodology is to transform the Haskell description in a principled way to a
corresponding conceptual specification, and implementing a C++ framework based on
that specification. In the nutshell, we reflect the Haskell types from the previous section
using concepts so that, for example, function types and type constructors are expressed
by concepts. This allows our library to freely glue existing code bases by plugging
them into well defined “slots” given by concepts. The algorithms and combinators are
expressed as generic functions and types, respectively. We present our methodology in
more detail in the remainder of this section, as we describe the particular elements of
our library.
The approach is split into two libraries. The first one, discussed in Sect. 3.1, is the
encoding of basic functional-programming types and features. As such, this library is
useful, or even strictly necessary, for any future development styled after our work. The
second library (Sect. 3.2), building upon the first one, introduces the notions necessary
for monadic dynamical systems.
3.1. A Functional Concepts Library
The Haskell description of monadic dynamical systems, as shown in Sect. 2, uses
the features of Haskell that make it a language so well suited for computable specifications.
In particular, functions and categorial constructs such as monads or functors can
be easily represented in the type system using first-class function types and type constructors.
In this section, we encode these high-level features in a generic manner that
makes it possible to reimplement them in non-functional languages and bridge them
with existing code bases.
We begin with the most basic concept underlying the specification of vulnerability:
functions. In the Haskell description from Sect. 2, we use the built-in function type
(->). This makes perfect sense in the setting where clarity is of topmost importance. In
general, however, there are many programming languages that do not provide a built-in
function type. Function types are available in C++, but they are only useful for forming
function pointers and meta-programming. As discussed by Lincke and Schupp (2009)
there are multiple ways of implementing mathematical functions in C++. Lincke and
Schupp consider mostly the efficiency of different implementations, but integration of
legacy code is equally important, at least in our setting. A scientist wishing to employ
our vulnerability library may have an existing and potentially complex platformspecific
implementation of particular functions. Therefore, instead of using a particular
type, we introduce a Function concept that captures the basic requirements on a type
implementing functions. Every type which models unary functions has to provide the
following entities:
• an associated domain type (called Domain1 3 ),
3 We choose the name Domain1 over just Domain for consistency with higher-arity function concepts.
17

• an associated codomain type (called Codomain),
• and an application operator mapping elements of the domain into the codomain.
The function concept containing these associated entities is implemented directly:
1 // Fun ~ a -> b
2 concept Function {
3 typename Domain1;
4 typename Codomain;
5
6 Codomain operator () (Fun, Domain1);
7 };
Although the call operator, as written above, takes an object of type Fun as one of
its arguments, the actual syntax of a function call on types modelling the concept is
f(x) where f is of type Fun and x is of type Domain1.
In general, crucial domain notions from the Haskell description are translated into
concepts, class templates, or generic functions, depending on their role in the library.
For example, our library provides a function composition operator, implemented as
a class template “typed” with concepts, that given two functions as input provides a
composed function:
1 // F ~ a -> b, G ~ b -> c
2 template
3 requires
4 std::CopyConstructible, std::CopyConstructible,
5 std::SameType
6 class Composed_Function {
7 public:
8 typedef F::Domain1 Domain1;
9 typedef G::Codomain Codomain;
10
11 // The constructor just stores f in my_f and g in my_g
12 Composed_Function(F f, G g) : my_f(f), my_g(g) {}
13
14 Codomain operator() (Domain1 x) const { return my_g(my_f(x)); }
15 private:
16 F my_f;
17 G my_g;
18 };
The Composed_Function combinator is implemented as a constrained class template.
Its constraints correspond to the Haskell type signature (a->b)-> (b->c)-> (a->c)
by stating that the two type parameters must each be models of the Function concept.
Domains and codomains of the functions are left unspecified (type variables a, b, and
c in the Haskell type), making Composed_Function polymorphic in the domains and
codomains of the composed functions. There is, however, a constraint that the codomain
of the first function must be the same as the domain of the second function (the
SameType requirement), corresponding to reuse of the type variable b in the Haskell
type. The CopyConstructible requirements are a technical necessity in C++, since ob-
18

jects representing functions are copied and stored for later use via the initialisation list 4
in the Composed_Function constructor. The result type, (a->c) in Haskell, is not a part
of the definition of the Composed_Function combinator. Instead, the result type must
be provided by a concept map stating that any Composed_Function object is a function
itself:
1 template
2 // requirements forwarded from Composed_Function
3 concept_map Function {
4 typedef F::Domain1 Domain1;
5 typedef G::Codomain Codomain;
6
7 // the binding for operator() is implicitly generated by the compiler
8 }
The above concept map states that all instantiations of Composed_Function model the
Function concept. The requirements on the F and G template arguments of the concept
map are propagated from the definition of the Composed_Function combinator, so that
they do not have to be copied and pasted. The associated types of the Function concept
are stated explicitly, while the application operator is matched automatically (by name)
to the appropriate definition in the Composed_Function template. The concept map
just states that Composed_Function is a function, but the correspondence between the
types of parameters and the type of the resulting composed function is encoded by the
definition of Composed_Function and does not result from the concept map alone.
While, by design, our Function concept is presented in C++, the methodology of
the translation is, besides technicalities, language-independent:
• for every generic function we have to provide a new (parameterised) type,
• constraints are used to capture the intended functional signature of this type,
• if the codomain of the function is itself a function type, we have to also introduce
a new type for the codomain (and so on),
• every new type which is intended to model a function has to be declared as a
model of the Function concept.
In a similar manner, our library provides more function-related features. For convenience,
we provide multiple argument function concepts such as Function2, Function3,
and so on. In addition to the composition combinator, we provide function currying.
Both composition and currying are extended to functions with multiple parameters.
All combinators in our library come with convenience functions that make applying
the combinators easier. For example, a compose function is provided for function composition:
1 template
2 requires
3 std::CopyConstructible, std::CopyConstructible,
4 Initialisation list appears after the colon following the constructor.
19

4 std::SameType
5 Composed_Function compose(F f, G g) {
6 Composed_Function ret(f, g);
7 return ret;
8 }
Such a function is easier to apply than directly constructing a Composed_Function
object because C++ automatically deduces template parameters from function call arguments.
A full list of Function-related operations may be found in the library source
code (Lincke, 2010).
The description of vulnerability in Sect. 2 depended on type constructors to represent
categorial notions such as monads or functors. As before, we do not rely on a
particular type or language construct to represent type constructors, but, instead, we
represent type constructors as concepts so that various implementations of type constructors
can be used.
C++ does not provide support for first-class type constructors. Concepts with template
template parameters, that is, template parameters that themselves must be templates,
are the most obvious encoding for type constructors where template parameters
represent type constructors. In practise, however, they are not well supported, and are
rarely used by C++ programmers. Also, such higher-order encoding would force programmers
to represent type constructors using a specific language mechanism (every
constructor would be a template), a restriction we have specifically set out not to impose.
Accordingly, we represent type constructors (of the Haskell kind * ->*) with a
ConstructorType concept parametrised by a plain template parameter. The concept
provides three one associated entities: a template that represents type constructor application,
an associated type which represents the type the constructor is applied to,
and an associated requirement ensuring the consistency of all the ingredients:
1 // T ~ f :: *->*
2 concept ConstructorType {
3 template
4 class Apply;
5
6 typename Inner;
7
8 // enforce a connection between T, Inner and Apply
9 requires std::SameType;
10 }
A reader familiar with type constructors may be immediately baffled by Inner member
and the SameType requirement. We introduced the two to get around limitations of the
C++ type system. The problem is that, in general, application of two different constructor
types may result in the same type causing injectivity issues when pattern matching
on type constructor applications. To avoid injectivity problems, our ConstructorType
concept introduces an artificial requirement that the constructor type tag T actually be
an application of the constructor. The SameType requirement is used to establish a connection
between the the constructor type T, the Apply operation, and the Inner type.
If the constructor type T is applied to Inner, the result has to be T. Therefore it is not
possible to declare an arbitrary type to be a type constructor. Our Haskell version of
20

the ConstructorType concept in Sect. 4 is more ideal, relying on the feature of associated
data types to prevent injectivity errors. A similar technique could be used in C++,
but since there is no feature corresponding directly to associated data types, it would
have to be encoded severely complicating our library. We believe that in connection
with template concept maps, our “trick” works out well. For instance, the std::vector
template from the STL is a type constructor:
1 template
2 concept_map ConstructorType {
3 template
4 using Apply = std::vector;
5
6 typedef T Inner;
7 }
The concept map states that any instantiation of the std::vector template has an associated
type constructor application, and it provides the application argument Inner
for pattern matching on particular applications.
Furthermore, we provide a SameTypeConstructor concept that models equivalence
between constructors similarly to how std::SameType concept models equivalence between
types. In addition, as for functions, we provide concepts for type constructors of
different arities.
Using these simple concepts, we model more complex concepts. The Functor concept
refines the notion of a type constructor. In Haskell, a functor is a type constructor
with one additional (polymorphic) operation called fmap:
1 class Functor f :: *->* where
2 fmap :: (a -> b) -> f a -> f b
Using the ConstructorType concept, we represent functors as follows:
1 // F is a ConstructorType that is a Functor
2 concept Functor : ConstructorType {
3 template
4 F::Apply fmap(Fun, F::Apply);
5 }
We first require that a functor type F be a type constructor by refining the concept
ConstructorType, thus making the Functor correspond to a Haskell type constructor
class. Then, fmap is provided as an associated member, just as in Haskell, using the
type constructor Apply template.
Models for the Functor concept are provided by defining the fmap function, as, for
instance, for the std::vector (taking into account the previously defined concept map
for the ConstructorType concept):
1 template
2 concept_map Functor {
3 template
4 ConstructorType::Apply
5 fmap(Fun f, ConstructorType::Apply fx) {
6 ConstructorType::Apply ret(fx.size());
7 for (unsigned int i=0; i

8 ret[i] = f(fx[i]);
9 return ret;
10 }
11 }
Monads are defined similarly to functors. The Monad concept also refines the
ConstructorType concept. It provides two polymorphic member functions mbind and
mreturn corresponding to the following Haskell signatures:
1 class Monad (m :: *->*) where
2 mbind :: m x -> (x -> m y) -> m y
3 mreturn :: x -> m x
Using the previously defined concepts ConstructorType and Function, the signatures
are translated into the Monad concept:
1 // M is a ConstructorType that is a Monad
2 concept Monad : ConstructorType {
3 template
4 requires
5 ConstructorType,
6 std::SameType
8 Fun::Codomain mbind(M::Apply, Fun);
9
10 template
11 M::Apply mreturn(X);
12 }
3.2. C++ Implementation of Monadic Dynamical Systems
In the previous section, we describe how to represent fundamental functional types.
These basic building blocks are necessary for any library in the style we propose. In this
section, we proceed to the notions specific to our domain of vulnerability modelling.
3.2.1. The Concept Framework
Using the concepts from the functional C++ framework from the previous section,
we can describe the ingredients of monadic systems. Coalgebras, which are functions
of type x -> f x where f is a functor, play an important role in our framework. A
general concept for a coalgebra refines the Function concept and adds the following
requirements:
• the codomain type has to be an application of a functor type (f x),
• and the type the functor is applied to (x) has to be the domain type.
The Coalgebra concept expresses these requirements using the concepts Functor and
std::SameType:
1 // Fun ~ x -> f x
2 concept Coalgebra : Function {
3 requires
22

4 Functor,
5 std::SameType;
6 }
Similarly, using the Monad concept, we define a concept for monadic coalgebras,
which are functions x -> m x for a monad m. A monadic coalgebra refines the idea of
a coalgebra with an addition of the requirement that the type constructor applied in the
codomain has to be a monad, not only a functor:
1 // Fun ~ x -> m x
2 concept MonadicCoalgebra : Coalgebra {
3 requires Monad;
4 };
As seen in Sect. 2, functions of type f :: i -> x -> m x where m is a monad are
of special interest for monadic systems with an external control (realised as an input
to the system). We call such functions monadic coalgebras with input, while functions
where only a functor is required are called coalgebras with input. The latter refines the
concept Function2 (binary function) by adding two requirements:
• the codomain type has to be a application of a functor type constructor,
• and the argument in the application has to be the second domain type.
The concept MonadicCoalgebraWithInput refines the concept CoalgebraWithInput
by stating that the codomain type has to be a monad type:
1 // Fun ~ (i,x) -> f x
2 concept CoalgebraWithInput : Function2 {
3 requires
4 Functor,
5 std::SameType;
6 };
7
8 // Fun ~ (i,x) -> m x
9 concept MonadicCoalgebraWithInput : CoalgebraWithInput {
10 requires
11 Monad;
12 };
Using that hierarchy of concepts, we specify the main concept of our library, the
one for monadic systems:
1 // Sys ~ ((t,x) -> m x)
2 concept MonadicSystem : MonadicCoalgebraWithInput {
3 typename MonoidOperation;
4 requires
5 Monoid,
6 std::SameType;
7
8 // axioms (in pseudocode):
9 // Sys(0) = return
10 // Sys(t1 + t2) = (Sys t1

The MonadicSystem concept refines the concept for a monadic coalgebra with input and
therefore inherits all requirements from there. There is just one associated entity: an
associated type that represents a monoid operation on the domain type of the monadic
system. The Monoid requirement on Line 5 implies a Function requirement, and the
type identity requirement on Line 6 ensures that the monoid element type is the same as
the domain type of the monadic system. Finally, monadic system must obey two laws,
which are expressed in comments. The first axiom states that the neutral element of the
domain monoid has to be mapped to monadic return, and the second axiom states that
the binary operation of the monoid should be mapped to Kleisli composition.
3.2.2. The Concept Framework as a Type System
Concepts, such as the ones presented in this section, build the type system of our
library. The domain of vulnerability is now freed from particularity of types, and even
such basic notions as functions are under the control of a user who may plug in implementations
into the interface. Next, we give examples of generic constructors and
algorithms implemented in our library.
In Sect. 2.3, we have introduced a constructor for monadic systems with input,
called input_system. Our C++ library provides a similar constructor:
1 // Trans ~ (i,x) -> m x; Cont ~ [i]
2 template
3 requires
4 std::SameType
5 class Monadic_System_With_Input {
6 public:
7 typedef Cont Domain1;
8 typedef Trans::Domain2 Domain2;
9 typedef Trans::Codomain Codomain;
10 typedef Concatenation Op1;
11
12 Monadic_System_With_Input(Trans const& trans) : my_trans(trans) {}
13
14 Codomain operator()(Domain1 const& l, Domain2 const& x) const {
15 Codomain ret = mreturn (x);
16 for (unsigned int i=0; i

ators (operator()) must be provided as a class members though, since they accesses
private class variables.
The monadic systems library contains generic functions which implement the algorithms
developed in the formalisation. As an example, we discuss the macro_trj
function from Sect. 2.3:
1 macro_trj :: (Monad m) => (i -> (x -> m x)) -> [i] -> x -> [m x]
2 macro_trj sys ts x = scanr (\i mx -> mx >>= sys i) (return x) ts
The macro_trj is translated to the following C++ implementation:
1 // Mon_Sys ~ (i,x) -> m x; Inp_Iter ~ [i]; Cont ~ [m x]
2 template
4 requires
5 std::SameType,
6 std::SameType
7 Cont
8 macro_trajectory(Mon_Sys const& sys,
9 Inp_Iter controls_bg, Inp_Iter controls_end,
10 Mon_Sys::Domain2 x) {
11 Cont macro_trj;
12 std::insert_iterator macro_trj_iter(macro_trj, macro_trj.begin());
13
14 // Mon_Sys::Codomain ~ (m x).
15 *macro_trj_iter = mreturn (x);
16
17 Mon_Sys::Codomain::Codomain mx = *macro_trj.begin();
18 while(controls_bg != controls_end) {
19 // Mon_Sys::Codomain ~ (m x) is the monad type.
20 // mbind is called for that monad m.
21 mx = mbind(mx, curry(sys)(*controls_bg)); ++controls_bg;
22 ++macro_trj_iter; *macro_trj_iter = mx;
23 }
24
25 return macro_trj;
26 }
The two lines in Haskell correspond to a much longer implementation in C++. Most
of the verbosity is due to concept-based type signature. It should be noted that we use
the C++ iterator mechanism to implement a function which is even more generic than
the equivalent Haskell version: in contrast to the Haskell function, where we handle all
sequences as Haskell lists, we do not have a fixed sequence type for the input (nor for
the output) in the C++ version. On the other hand, we have not reimplemented Haskell’s
scanr, which makes our implementation more verbose.
In addition to the constructors and generic algorithms we shown here our library
provides also combinators, in particular Monadic_Systems_Parallel and
Sys_Ser_Function. As a final example how our libraries can be used we
present a vulnerability computation algorithm encoded with the concepts from our libraries
in the next section.
25

3.3. Application of the Monadic Systems Library in Vulnerability Assessment
The framework of concepts, operation and combinators presented so far can be
used to implement vulnerability computation as introduced in Sect. 2.3. The signature
of such computations, as for instance
1 vulnerability’ :: (Functor m, Monad m) =>
2 (i -> x -> m x) -> ([x] -> h) ->
3 (m h -> v) -> [i] -> x -> v
4 vulnerability’ sys harm measure ts = measure . fmap harm . micro_trj sys ts
has to be encoded with requirements. For functions types we use the Function concept,
and type identities are expressed with std::SameType requirements:
1 template
3 requires
4 ConstructorType, Monad,
5 std::SameType,
6 std::SameType,
7 std::SameType
8 Meas::Codomain
9 vulnerability_sys(Sys sys, Harm harm, Meas measure, Crtl ts,
10 Sys::Domain2 x) {
11 typedef
12 Sys::Codomain::Apply
13 Micro_Trj_Type;
14
15 Micro_Trj_Type micro_trj;
16
17 micro_trajectories(sys, x, ts.begin(), ts.end(), micro_trj);
18 return measure(fmap (harm, micro_trj));
19 }
It should be noted that encoding the function signature with concepts is more complex
than the functional signature. Otherwise the implementation is not much different from
the functional implementation because technical details such as the iterator mechanism
are hidden in the computation of micro-trajectories.
4. Reimplementation in concept-based Haskell
The general concepts presented in section Sect. 3.2 are not only implementable in
C++ but also in any language which provides an appropriate support of generic programming
with concepts. To illustrate what implementations in other languages could
look like, we sketch a monadic systems library in concept-based Haskell.
Recent additions of support for associated types to the GHC Haskell compiler
(Chakravarty et al., 2005; Schrijvers et al., 2008) allows us to express the C++ concept
framework also in Haskell (with extensions). We have ported our C++ implementation
“back to Haskell” and interesting future work would be to make this port more complete
and to compare the expressivity and efficiency of the generated code. Below is a
sample of the Haskell version using associated types. The full Haskell development is
26

available as an experimental Cabal package with 43 modules and 1700 LOC (including
comments).
We start with the Function concept as a Haskell type class with a standard modelling
(instance) for the built-in function type. As Haskell does not allow overloading
the application operator, we use an infix operator (!):
1 class Function fun where
2 type Domain fun
3 type Codomain fun
4 (!) :: fun -> (Domain fun -> Codomain fun)
5
6 instance Function (a -> b) where
7 type Domain (a -> b) = a
8 type Codomain (a -> b) = b
9 f ! x = f x
Next, we move to the ConstructorType concept where we use GHC’s support for
infix type constructors to make later definitions a bit more readable.
1 class ConstructorType con where
2 data (:@) con :: * -> *
3 type Apply = (:@)
The full code also includes three more associated entities.
For the next example (monads) we need equality constraints: a ~ b is the Haskell
equivalent of SameType in C++ with Concepts. We name the Function type variable
a2mb (short for “a to m b”):
1 class ConstructorType m => Monad m where
2 mbind :: (Function a2mb, Codomain a2mb ~ (m :@ b)) =>
3 m :@ Domain a2mb -> a2mb -> Codomain a2mb
4 mreturn :: a -> m:@a
Note that the equality constraint means that the same type can be expressed in different
ways: in this example Codomain a2mb can freely be replaced by m:@b. In general,
not only can equals be substituted for equals, but we can also effectively add type
subexpression aliases as in the following example:
1 mbind’ :: ( Monad m, Function a2mb
2 , a ~ Domain a2mb
3 , mb ~ Codomain a2mb
4 , ma ~ (m :@ a)
5 , mb ~ (m :@ b)
6 ) =>
7 ma -> a2mb -> mb
8 mbind’ = mbind
In fact, equality constraints are sufficiently powerful to take us to the limit of what
GHC can handle. When encoding the Coalgebra concept we had to comment out the
equality constraint to avoid a compiler error 5 :
5 Both GHC 6.12 and GHC 7.0.1 say “The current implementation of type families does not support
equality constraints in superclass contexts. They are planned for a future release.”
27

1 class ( Function a2fb
2 , Functor (FunctorTag a2fb)
3 -- , Codomain a2fb ~ (FunctorTag a2fb :@ Domain a2fb)
4 ) => Coalgebra a2fb where
5 type FunctorTag a2fb :: *
Our final example (in Fig. 4) is the generic vulnerability calculation where we use
equality constraints to document the type structure in detail (making it just as verbose
as the C++ version).
1 vulnerability_sys ::
2 ( MonadicSystem sys , Function harm
3 , i ~ Domain sys , [x] ~ Domain harm
4 , x2mx ~ Codomain sys , h ~ Codomain harm
5 , x ~ Domain x2mx , Function meas
6 , mx ~ Codomain x2mx , mh ~ Domain meas
7 , m ~ FunctorTag x2mx , v ~ Codomain meas
8 , mx ~ (m:@x) , mh ~ (m :@ h)
9 ) => sys -> harm -> meas -> [i] -> x -> v
10 vulnerability_sys sys harm meas is x = v
11 where mxs = micro_trj sys is x
12 mh = fmap harm mxs
13 v = meas ! mh
Figure 4: The generic vulnerability calculation in Haskell with concepts.
While porting the concepts code from C++ to Haskell we had to make a number
of technical choices (associated types versus associated datatypes, type inference versus
explicit type application, etc.) where the languages differ. A detailed description
would take as too far off topic but there is certainly some scope for future work in this
direction.
One issue that deserves attention, however, is our use of associated datatypes. An
attentive reader may have noticed that the Haskell ConstructorType concept does not
impose the same constraints on the tag as the C++ version on page 20. Haskell’s associated
datatype introduces a wrapper, which is one of the solutions we discussed in
the discussion of the C++ ConstructorType concept. Thanks to that wrapper, one can
always map a constructor type application back to the appropriate instance, avoiding
injectivity errors 6 . Yet, the wrapper does not come without a price. The programmer
must now wrap and unwrap values where necessary, which is impossible to do
generically. To avoid that issue, the actual ConstructorType class introduces extra
machinery:
1 class ConstructorType con where
2 data (:@) con :: * -> *
3 type Applied con :: * -> *
4 unapply :: con :@ a > Applied con a
6 http://www.haskell.org/haskellwiki/GHC/Type_families
28

Constructor type application produces a wrapped value, but we also provide generic
apply and unapply functions that can move back and forth between wrapped and unwrapped
values. The associated type Applied corresponds to the Apply template in the
C++ version of this concept.
5. Related Work
In the realm of generic programming, the use of concepts (or type classes) to abstract
from representations of data or to capture certain properties of types is a common
practise. For example, the C++ Standard Template Library (STL) (Austern, 1998;
Stepanov and Lee, 1994) introduces a hierarchy of concepts for data containers and for
iterators used to generically traverse ranges of data, and the Boost Graph Library (Siek
et al., 2002) introduces concepts representing different kinds of graphs. In the traditional
approach, functional notions such as monadic system, for example, are either
not represented explicitly at all (in C++ libraries) or are represented by a particular type
(as in Haskell libraries). In our generic library for vulnerability assessment, we take
abstraction further in conceptually representing functions as well as data. In Haskell,
almost all libraries are generic in the sense that they use and define type classes. Some
more advanced examples are (Chakravarty et al., 2005; Claessen and Hughes, 2000;
Jansson and Jeuring, 2002; Oliveira et al., 2006)
Recently, new concept applications have been enabled (and inspired) by the linguistic
support for concepts in C++0x (Gregor et al., 2006). For example, much of the standard
library of C++ (including the STL) has been conceptualised, that is, rewritten using
the new concepts feature (for example, Gregor et al., 2008a,b). This body of code and
specifications provides a good example of how generic libraries will be written when
concepts officially become a feature of C++. Our work goes further than STL concepts.
The first difference is that we systematically tackle type constructor concepts; the only
similar concept in STL is the Allocator concept (Halpern, 2008), which requires compiler
support to verify constraints that are expressed using SameTypeConstructor concept
in our framework. The other difference is in handling of computations: in our
framework a computation is represented by a self-contained Function concept that
knows its domain and codomain types, while in the conceptualised STL a computation
is represented by a Callable family of concepts that require domain types as concept
arguments.
One aspect of our work is implementation of functional programming constructs
in C++. Related work has been done before, including the Boost Lambda library (Järvi
et al., 2003), the FC++ library (McNamara and Smaragdakis, 2004b), and the Boost
Fusion library (de Guzman and Marsden, 2009). All the previous approaches rely
heavily on template meta-programming, while we encode the types of functions on the
level of concepts.
A related project with similar goals as our work is the DUNE (Distributed and Unified
Numerics Environment) project (Bastian et al., 2008). DUNE identifies an abstract
specification of a parallel and adaptive hierarchical grid for scientific computing, but
without providing a functional prototype implementation. C++ template programming
is employed to achieve an efficient implementation of this specification which supports
29

with reuse of existing finite element packages. Concepts are used implicitly to specific
the type parameters of the templates.
Botta and Ionescu develop a generic C++ library for parallel computing using a
Haskell prototype as a model and a specification. While concepts are not used explicitly
there is a common idea between their work and the approach presented in this paper.
This paper can also be seen as continuing the line of work relating concepts in
Haskell and C++: (Bernardy et al., 2010, 2008; Garcia et al., 2007b; Zalewski et al.,
2007).
6. Discussion and Future Work
We presented an approach to express domain notions in a functional model and afterwards
transform them into generic concepts. This enables us to implement domainspecific
high-performance libraries from functional models. We have illustrated our
approach by implementing a library for monadic dynamical systems, a useful model of
systems involved in vulnerability modelling in the context of climate change. A functional
description of monadic dynamical systems and algorithms is provided in the first
part of this paper, in the second part we implement a concept-based generic C++ library
from this executable functional specification.
Our approach is flexible, we don’t have to stick to C++ and Haskell. The functional
modelling can be done in other functional languages or even in a more mathematical
notion like the typed λ-calculus. As we have shown, the implementation of the final
library can also be done in concept-enabled Haskell. But what language features are
necessary to apply our approach? First of all, the language has to provide a mechanism
to allow generic programming with concepts. This include a possibility to implement
concepts, a notion for refinement, a mechanism for modelling and support for
constraining generic algorithms. Besides, Bernardy et al. studies advanced language
features for generic programming with concepts. Fig. 5 summarises language features
which are necessary for implementing a generic library with our approach. Only a few
Feature
Necessary for
Multi-type concepts Concepts modelling type identities as for instance in std::SameType
Multiple constraints Encoding complex function signatures as in vulnerability_sys
Parametric modelling Declare models for our ConstructorType concept
Associated type access Encoding function signatures of member functions, for instance mbind in
Monad.
Constraints on associated
types
Encoding type relations between associated types and type parameters,
for instance in the ConstructorType concept.
Type equality constraints Encoding type equalities in complex function signatures as in
vulnerability_sys
Figure 5: Language features (using terminology from Bernardy et al.)
concept-based generic library with our approach.
that are necessary to develop a
features are really essential, while some other features (like constraint and type aliases)
are useful for more convenient coding but not necessary for implementing a library.
The transformation of types from a functional style into Function-concept style
follows a well defined scheme and can therefore be automated. In a nutshell, a function
30

type f :: X -> Y is flattened by replacing higher order function types in the domain
type and the codomain type. Higher order function types in the domain are replaced by
type parameters and concepts are used to encode their signature. In the codomain type,
a new type is introduced for every higher order function type and the original higher
order function type is replaced by it. We currently working on a compiler that does this
transformation. 7
Acknowledgements
The authors would like to thank Jean-Philippe Bernardy, Nicola Botta, Andreas
Priesnitz, Gustav Munkby and Sibylle Schupp for their insightful comments and interesting
discussions. The research in this paper was partly supported by a grant from the
European Union research project ADAM under Contract number GOCE-018476 and
by a grant 0702717 from National Science Foundation.
References
Adger, W. N., 2006. Vulnerability. Global Environmental Change 16, 268–281.
Austern, M. H., 1998. Generic Programming and the STL: Using and Extending the
C++ Standard Template Library. Addison-Wesley.
Bastian, P., Blatt, M., Dedner, A., Engwer, C., Klöfkorn, R., Kornhuber, R., Ohlberger,
M., Sander, O., July 2008. A generic grid interface for parallel and adaptive scientific
computing. part ii: implementation and tests in dune. Computing 82, 121–138.
Bernardy, J.-P., Jansson, P., Zalewski, M., Schupp, S., 2010. Generic programming
with C++ concepts and Haskell type classes—a comparison. J. Funct. Program.In
press.
Bernardy, J.-P., Jansson, P., Zalewski, M., Schupp, S., Priesnitz, A., 2008. A comparison
of C++ concepts and Haskell type classes. In: Proc. ACM SIGPLAN Workshop
on Generic Programming. ACM, pp. 37–48.
Botta, N., Ionescu, C., 2007. Relation-Based Computations in a Monadic BSP Model.
Parallel Computing 33 (12), 795–821.
Brooks, N., 2003. Vulnerability, risk and adaptation: A conceptual framework. Tyndall
Center Working Paper 38.
Chakravarty, M. M. T., Keller, G., Jones, S. P., 2005. Associated type synonyms. In:
ICFP ’05: Proc. tenth ACM SIGPLAN international conference on Functional programming.
ACM, pp. 241–253.
7 See the project page http://www.pik-potsdam.de/members/lincke/haskc-generic-c-programming-fromhaskell-specification
31

Claessen, K., Hughes, J., 2000. QuickCheck: A lightweight tool for random testing of
Haskell programs. In: ICFP’00: International Conference on Functional Programming.
ACM, pp. 268–279.
Garcia, R., Jarvi, J., Lumsdaine, A., Siek, J., Willcock, J., Mar. 2007a. An extended
comparative study of language support for generic programming. J. Funct. Program.
17 (2), 145–205.
Garcia, R., Jarvi, J., Lumsdaine, A., Siek, J., Willcock, J., 2007b. An extended comparative
study of language support for generic programming. J. Funct. Program. 17 (2),
145–205.
Gregor, D., Järvi, J., Siek, J., Stroustrup, B., Dos Reis, G., Lumsdaine, A., 2006.
Concepts: Linguistic support for generic programming in C++. In: Proc. ACM SIG-
PLAN Conf. on Object-Oriented Programming, Systems, Languages, and Applications
(OOPSLA). ACM Press, pp. 291–310.
Gregor, D., Marcus, M., Witt, T., Lumsdaine, A., 2008a. Foundational concepts
for the C++0x standard library (rev. 4). Tech. Rep. N2737=08-0247, ISO/IEC
JTC1/SC22/WG21 - C++.
Gregor, D., Siek, J., Lumsdaine, A., 2008b. Iterator concepts for the C++0x standard
library (rev. 4). Tech. Rep. N2739=08-0249, ISO/IEC JTC1/SC22/WG21 - C++.
Gregor, D., Stroustrup, B., Widman, J., Siek, J., 2008c. Proposed wording for concepts
(rev. 8). Tech. Rep. N2741=08-0251, ISO/IEC JTC1/SC22/WG21 - C++.
de Guzman, J., Marsden, D., 2009. Fusion library homepage. http://www.boost.org/
libs/fusion.
Halpern, P., 2008. Defects and proposed resolutions for allocator concepts. Tech. Rep.
N2810=08-0320, ISO/IEC JTC1/SC22/WG21 - C++.
Ionescu, C., 2009. Vulnerability modelling and monadic dynamical systems. Ph.D.
thesis, Freie Universität Berlin, available from http://www.diss.fu-berlin.de/
diss/receive/FUDISS_thesis_000000008403.
Janssen, M. A., Ostrom, E., 2006. Resilience, vulnerability and adaptation: A crosscutting
theme of the international human dimensions programme on global environmental
change. Global Environmental Change 16 (3), 237–239, editorial.
Jansson, P., Jeuring, J., 2002. Polytypic data conversion programs. Science of Computer
Programming 43 (1), 35–75.
Järvi, J., Powell, G., Lumsdaine, A., 2003. The lambda library: Unnamed functions in
C++. Software: Practice and Experience 33 (3), 259–291.
Jones, M. P., 1993. A system of constructor classes: overloading and implicit higherorder
polymorphism. In: Proc. Conference on Functional Programming Languages
and Computer Architecture (FPCA). ACM, New York, NY, USA, pp. 52–61.
32

King, D., Wadler, P., 1992. Combining monads. In: Launchbury, J., Sansom, P. M.
(Eds.), Glasgow Workshop on Functional Programming. Springer-Verlag, pp. 134–
143.
Lincke, D., 2010. Functional C++ with concepts. Last checked: 2010-12-27.
Lincke, D., Jansson, P., Zalewski, M., Ionescu, C., 2009. Generic libraries in C++ with
concepts from high-level domain descriptions in Haskell: A DSL for computational
vulnerability assessment. In: IFIP Working Conf. on Domain Specific Languages.
Vol. 5658/2009 of LNCS. pp. 236–261.
Lincke, D., Schupp, S., 2009. The function concept in C++- an empirical study. In:
WGP ’09: Proc. ACM SIGPLAN workshop on Generic programming. ACM, pp.
25–36.
McNamara, B., Smaragdakis, Y., 2004a. Functional programming with the fc++ library.
Journal of Functional Programming 14 (4), 429–472.
McNamara, B., Smaragdakis, Y., 2004b. Functional programming with the FC++ library.
J. of Functional Programming 14 (4), 429–472.
Myers, N., 1995. A new and useful template technique: “Traits”. C++ Report 7 (5), 35,
32.
Oliveira, B. C. d. S., Hinze, R., Löh, A., 2006. Extensible and modular generics for the
masses. In: Nilsson, H. (Ed.), Trends in Functional Programming. pp. 199–216.
Petoukhov, V., Ganopolski, A., Brovkin, V., Claussen, M., Eliseev, A., Kubatzki, C.,
Rahmstorf, S., 2000. CLIMBER-2 : a climate system model of intermediate complexity.
Part I : model description and performance for present climate. Climate dynamics
16, 1–17.
Peyton Jones, S. (Ed.), 2003. Haskell 98 Language and Libraries: The Revised Report.
Cambridge University Press.
Schrijvers, T., Peyton Jones, S., Chakravarty, M., Sulzmann, M., 2008. Type checking
with open type functions. In: ICFP ’08: Proc. 13th ACM SIGPLAN international
conference on Functional programming. ACM, pp. 51–62.
Siek, J. G., Lee, L. Q., Lumsdaine, A., 2002. The Boost Graph Library: User Guide
and Reference Manual. Addison-Wesley.
Stepanov, A. A., Lee, M., 1994. The Standard Template Library. Tech. Rep. HPL-94-
34, Hewlett-Packard Laboratories, revised in October 1995 as tech. rep. HPL-95-11.
Stroustrup, B., 1997. The C++ Programming Language, 3rd Edition. Addison-Wesley.
Wadler, P., Blott, S., 1989. How to make ad-hoc polymorphism less ad hoc. In: Proc.
16th ACM SIGPLAN-SIGACT Symp. on Principles of Programming Languages
(POPL). ACM Press, pp. 60–76.
33

Wolf, S., Lincke, D., Hinkel, J., Ionescu, C., Bisaro, S., 2008. A formal framework
of vulnerability. Final deliverable to the ADAM project. FAVAIA working paper 8,
Potsdam Institute for Climate Impact Research, Potsdam, Germany.
Zalewski, M., Priesnitz, A. P., Ionescu, C., Botta, N., Schupp, S., 2007. Multi-
Language library development: From Haskell type classes to C++ concepts. In:
Striegnitz, J. (Ed.), Proc. 6th Int. Workshop on Multiparadigm Programming With
Object-Oriented Languages (MPOOL).
34