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 post-walk 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: Trade-offs (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 sub-expressions
- A multiplication of a vector of sub-expressions

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 sub-expressions.

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 sub-expressions.

*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 sub-expressions 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 sub-expressions, 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 sub-expression 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 sub-expression transformation
- The second element of the pair is the sub-expression 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 sub-expression 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 sub-expression of addition and multiplication, our algebra has access to:

- The pretty printed sub-expression (first argument of the pair)
- The sub-expression itself (second argument of the pair)

We can therefore implement the pretty printing of the multiplication such that it adds parentheses around addition sub-expressions 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.