Clojure has a useful macro called cond-> that conditionally threads an initial value through a series of predicate/function pairs only applying each function if its predicate returns true. In this post we're going to look at a Scala representation, and whether it fits the shape and laws of any common algebraic structures. We'll look at Functor, Monad, Semigroup, and Monoid.

TL;DR — view the full code listing.

Let's start with an example in Clojure. We want to build up a request based on some arbitrary conditions:

Since Clojure's -> operator is sometimes referred to as the "thrush" operator, I'm going to call cond-> in Scala ThrushCond.

First let's model the Request and helpers equivalent to those we used in the Clojure example:

Now we'll create the ThrushCond class that takes any number of predicate/function pairs, provides a guard function to only run a function if the predicate passes, a method to flatten the chain of functions via composition, and finally a run method that takes a value and runs it through the chain.

Try it out:

As you can see, it correctly skipped the 2nd step based on the address.isDefined condition and runs the other steps because their predicates evaluate to true.

Will this work as one of the algebraic structures mentioned at the start?

Functor

Consider Functor's fmap:

In our case, both A are the same type, Request produces a function that fits, but we could easily use that with an existing Functor, e.g.:

The essense of ThrushCond itself so it makes no sense to design a new Functor around it.

Monad

Likewise, Monad's flatMap:

We could make guard's signature, but there's no point in doing so for the same reason it didn't make sense for Functor: the essense is not how a transformation is applied, it's whether the transformation is applied, and because of the signature, the decision whether to perform a transformation must be embedded in the transformation itself, hence guard.

Semigroup

Let's see if it meets Semigroup's associativity laws:

guard is associative when composed with itself because function composition is associative. Because of this associative binary operation we can provide evidence that ThrushCond's Semigroup representation:

We've defined a Semigroup over the set of all ThrushCond[A]s. What does this give us? We can now combine any number of ThrushConds using Semigroup's |+| operator. A simple example using ThrushCond[Int]:

Monoid via PlusEmpty

Monoids are Semigroups with an identity element. ThrushCond's identity is simply a ThrushCond arguments. However, as @lmm mentioned in the comments:

it's not ThrushCond itself that forms a Monoid but rather ThrushCond[A] for any given A

This is where PlusEmpty comes in. PlusEmpty is a "universally quantified Monoid" which means it's like a Monoid but for first-order * -> * types instead of proper * types. PlusEmpty itself is a higher-order (* -> *) -> * type. A helpful quote from #scalaz:

tpolecat: so String is a monoid, but List (which means that List[A])

To provide evidence of a PlusEmpty, we must be able to implement these two methods (where F):

We already implemented plus for Semigroup's append, and empty is simply a ThrushCond without args.

Let's go back to our Request example in Clojure and use PlusEmpty's <+> to combine separate transformation pipelines:

Because PlusEmpty can derive a Monoid for a given type, we can combine any number of ThrushConds from a List. Let's construct one more ThrushCond pipeline that conditionally adds a cache-control header and try out our Monoid using Foldable's suml:

ThrushCond is not a Monad, nor a Functor, but it is a PlusEmpty from which can be derived a Monoid.

View the full code listing.

Updated July 1, 2015: incorporated lmm's PlusEmpty suggestion.