Two months back, we went over the process of building a DSL for arithmetic operations and we introduced the concept of Catamorphism as a way to decouple the traversal of an AST
from the operations we want to perform on it.
We saw how it could help us compose operations
before traversing the AST of our DSL, leading to more efficient composition and better testability.
We did this exercise in Haskell, introducing the concept of Catamorphism through its wonderful type system. Then we tried it in Clojure only to see it was a simple postwalk tree traversal. We ended up by exploring the limits of its applicability in C++.
The full series of post is available below for reference:

Catamorph your DSL: Introduction
(Haskell) 
Catamorph your DSL: Deep Dive
(Haskell) 
Catamorph your DSL: Tradeoffs
(Haskell)  Catamorph your DSL: Clojure
 Catamorph your DSL: C++ Port
This post will build on top of the Catamorph your DSL: C++ Port
post. We will introduce, through a motivated use case, another very close and useful recursion scheme, Paramorphisms, and try to implement them in C++.
Reminder: Our Arithmetic DSL
Our Arithmetic DSL allows to build expression composed of operations like addition and multiplication of integer constants and integers variables. An arithmetic expression is one of the following:
 A constant value (and integer for simplicity)
 A variable (identified by a string for simplicity)
 An addition of a vector of subexpressions
 A multiplication of a vector of subexpressions
Because an AST alone is not very useful, we added several interpreters on our DSL to play with it. We implemented each of them in in the Catamorph your DSL: C++ Port
post:

prn
to pretty print our Arithmetic expressions 
eval
to compute the value of an expression, given the value of all variables 
optimize
to simplify and optimize our expression 
partial
to partially evaluate our expression, given the value of some variables 
dependencies
to retrieve not yet resolved variables from our expression
Reminder: Recursion Schemes
Looking at our interpreters, we noticed in our previous post that they all had in common the need to traverse the full AST. We used Catamorphisms to factorize this concern out of our interpreters.
This section is a short overview of what Catamorphism are for and how we implemented them in C++. You can skip it if you feel comfortable with the notion already.
Open recursion on types
To use Catamorphisms, we first need to generalize our Arithmetic expression
and make it an open recursive data type: expression_r
templated on a parameter type R
, which represents the type of the subexpressions.
An expression
of our DSL is then defined such as the template parameter R
is itself an expression. In more formal terms, expression
is the fixed point of the expression_r
type. We can compute it using CRTP
and boost::recursive_wrapper
.
Functor instance
We made our expression_r
type an instance of a Functor by implementing a fmap
function for our type. Note that by Functor here, we mean the mathematical construct
, and not function objects
.
The transformation map
given to fmap
applies on the template parameter of the expression_r
and may modify its type. In other words, fmap
allows to transform the subexpressions.
Note: because the function provided to fmap can have different types as input and output, the type of the template parameter of expression_r can change under fmap, and with it, the nature of the recursion.
Generic tree traversal
We then defined the cata
function, which implements the Catamorphism recursion scheme. It takes what we will call an algebra
as parameter, and returns a transformation on a whole AST.
The algebra is a function that takes an expression_r
templated on Out
, and outputs an Out
value.
The result of cata
on the algebra (curried) is a function that applies on a full expression
and returns an Out
value:
For instance, the following print_alg
algebra transforms an expression_r
templated on string into a string. Its goal is to implement a “pretty print” of the expression at one stage of the expression alone.
Given to cata
, it will become an function that transforms a complete expression
into a string, basically being promoted to operate on all stages of the expression.
The use case that breaks the pattern
Every single technique we use in Software Engineering has its limits. Outside of these limits, the technique will either not apply or might not be the best tool for the job. Catamorphisms are no exception to this rule.
Because Catamorphisms are a way to factorize a particular recursion scheme, it cannot apply for recursions that do not follow the given pattern. We will now explore one use case that demonstrates these limits.
Infix notation
Let us imagine that the client of our arithmetic DSL does not like the prefix notation of our pretty print function. Instead, he would like the arithmetic expressions to be pretty printed in infix notation. For example, 1 + y + x * 3
instead of (+ 1 y (* x 3))
.
Now, and contrary to the prefix notation which follows a pretty simple parenthesizing scheme, pretty printing in infix notation requires us to be careful. A wrong use of parentheses could change the meaning of the expression.
A first attempt
As a first approximation, we could use the following strategy for the placement of the parentheses in our infix notation:
 Systematically surround the arguments of a multiplication with parentheses
 Never surround the arguments of an addition with parentheses
Implementing the pretty printer that follows this strategy can be done using Catamorphisms. We use Boost
to make the code simpler:
We can try this first implementation on our test arithmetic expression:
What we get is is a correct result: the pretty printed expression has indeed the right meaning. But there are so much unneeded parentheses that the expression is really hard to read. We have to do much better.
Improving parenthesizing
To get better results, we need our infix notation to avoid adding useless pairs of parentheses. We know how to fix this: a multiplication only needs to add parentheses around subexpressions that correspond to additions.
Unfortunately, Catamorphisms are not a powerful enough recursion scheme to implement this logic. The algebra given to the Catamorphism has no access to the subexpressions, only their resulting string.
As a consequence, there is no way to know whether the expression was previously an addition (except by parsing it, which would truly be awful). The Catamorphism has failed us here: we need to turn to a different recursion scheme.
From Catamorphism to Paramorphism
The previous use case demonstrated us that we need the information on whether a subexpression is an addition when dealing with the multiplication.
We will turn to the recursion scheme known as Paramorphism
, which is like a Catamorphism but with added contextual information.
Paramorphisms
Paramorphisms are pretty close to Catamorphisms. The goal is identical: it turns a local transformation on an open recursive data structure into a global transformation on the fixed point of this data structure.
The difference is the prototype of the algebra given as parameter to the recursion scheme. Instead of taking the open recursive type parameterized on the output type of the transformation, the algebra takes a an open recursive type parameterized on a pair:
 The first element of the pair is the output of the subexpression transformation
 The second element of the pair is the subexpression before the transformation
In more concrete terms, and applied to our arithmetic expression, here are the prototypes for the algebra of catamorphism and paramorphism:
The second element of the pair is the contextual information. In our specific case, it will provide us with the information about the subexpression needed to make the right parenthesizing choice.
Paramorphism implementation
We will now implement the para
function, whose goal is to transform a local algebra into a global transformation on an arithmetic expression.
The implementation is very similar to the one of the Catamorphism. The only modification concerns the lambda provided to the fmap
function, which needs to return a pair instead of a single value:
Implementing the infix notation
We now have enough contextual information to implement our infix notation properly. For each subexpression of addition and multiplication, our algebra has access to:
 The pretty printed subexpression (first argument of the pair)
 The subexpression itself (second argument of the pair)
We can therefore implement the pretty printing of the multiplication such that it adds parentheses around addition subexpressions only.
We can try this second implementation on our test arithmetic expression. This result is clearly much better. The resulting infix notation has no unnecessary parentheses left:
Conclusion
This was the second post dedicated to the implementation of the recursion schemes often used in Haskell into C++.
Through a motivating use case, we discovered the limits of the Catamorphism recursion scheme, and learned about a new strictly more powerful one: Paramorphism.
Although typically unused in C++, we managed to provide a concise implementation of it. The result is clearly not as short and beautiful than in Haskell, but has the merit to show that it is not outside of the expressiveness range of C++.
You can access the full code of the DSL, along with all its associated interpreters, in this Gist
or alternatively in Ideone
.