One of the nice things about the succinct ways we have in Haskell for writing functions is that our predicates can read very naturally:

```
filter (> 5) [0 .. 10]
```

We can compose a chain of functions that produce a `Bool`

with normal function composition:

```
filter ((== 'c') . fst) [('a', 1), ('b', 2), ('c', 3)]
```

But often you want to compose predicates logically, with *and*, *or* and *not*, and while the syntax is lightweight, it still gets noisy enough to get in the way of our meaning. Imagine the decision process for deciding if a patron:

```
newtype Age = Age Int deriving (Show, Eq, Ord)
newtype BloodAlcohol = MgMl Double deriving (Show, Eq, Ord)
data Person = Person { age :: Age, bloodAlcohol :: BloodAlcohol }
```

Can be served a drink in a bar:

```
let drinkingAge = Age 18
legalLimit = MgMl 80.0
isOldEnough = (drinkingAge <=) . age
isDrunk = (legalLimit <=) . bloodAlcohol
in filter (\patron -> isOldEnough patron && not (isDrunk patron))
[ Person (Age 17) (MgMl 0.0) -- too young
, Person (Age 22) (MgMl 93.5) -- too drunk
, Person (Age 20) (MgMl 62.1) -- fine (for now)
]
```

That is ok, but having the thread the `patron`

argument to the two predicates and combine the results, well, it all feels a bit low level! Where is the abstraction? Can this not be more declarative? Perhaps our ideal syntax would be:

```
filter (isOldEnough <&> not' isDrunk) customers
```

So much nicer! And seriously, expressing intent like this means that logic is clearer, less obscured by the ceremony of argument passing, and hopefully easier to get right.

I remember searching in Hoogle for a function `f :: (b -> c -> d) -> (a -> b) -> (a -> c) -> a -> c`

so that I could create `(<&>)`

as `f (&&)`

, before realising that this could be done in a couple of different ways. The most obvious one (and the one that is used all the time in real code) is with *Functors* and *Applicatives* (see below for a brief discussion), which is natural given the 'fmappy' kind of thing we are trying to do here. While Hoogle still doesn't suggest the best answer for that query (we do get `Data.Function.Tools.apply2Way`

though, which has precisely the type we need), there are several ways to solve this problem, and perhaps surprisingly, *Monoids* are a perfectly suitable (if slightly round-about) way forwards. This is surprising because *Applicatives* and *Monoids* have different kinds, `* ->`

vs

*`*`

, and yet we can encode this little boolean algebra using either abstraction.

For this, we need to remind ourselves that monoids let us combine two similar things. Examples of this are concatenating two strings, unioning two sets, adding two numbers. The monoid class has the following methods:

```
class Monoid m where
mappend :: m -> m -> m -- also called (<>), and technically belongs to Semigroup
mempty :: m -- gets us the empty element
```

We are trying to combine two similar things! Specifically, two predicates into a third either by way of `(&&)`

or `(||)`

. We can be clear about this by naming that idea:

```
type Pred a = a -> Bool
```

Can we treat our `Pred`

as a Monoid? Yes! And the key is that along with the obvious things, such as strings and sets and numbers, functions also form a monoid, as long as they produce a monoid (here written as lambdas to make it clear that we are taking and returning functions):

```
instance Monoid b => Monoid (a -> b) where
mempty = \a -> mempty
mappend f g = \a -> f a <> g a
```

The `mappend`

instance is particularly interesting: it enables us to compose two functions to produce a third, but not in serial as with `(.)`

, but in parallel.

Unfortunately our `Pred a`

is not a Monoid yet, because there is no (one) Monoid instance for `Bool`

. In fact there are two. The second piece of the puzzle is that because there are multiple monoid instances for some data types, their different instances are associated with newtypes, to allow us to specify which one we mean.

Numbers have `Sum`

and `Product`

, representing the monoids `(+, 0)`

and `(*, 1)`

respectively. Objects with orderings (members of the *Ord*) have the semigroup instances `Min`

and `Max`

(where `(<>)`

is `min`

and `max`

) as well as *Monoid* instances if they are *Bounded*. Bools have `All`

and `Any`

, representing the monoids `(&&, True)`

and `(||, False)`

. With this in mind we can create our little predicate combinators:

```
combine :: (Functor f, Monoid (f m)) => (a -> m) -> (m -> b) -> f a -> f a -> f b
combine into outof f g = fmap outof (fmap into f <> fmap into g)
```

The `comb`

helper just encapsulates the common logic for mappending two `Pred a`

, by allowing the isomorphic functions that select the monoid to be passed in. With this we get:

```
(<&>), (<?>) :: Pred a -> Pred a -> Pred a
(<&>) = combine All getAll
(<?>) = combine Any getAny
not' :: Pred a -> Pred a
not' = (not .) -- helps us avoid brackets
```

and now we can compose complex conditions in their own terms, producing a simple boolean DSL, capable of handling even complex nested conditions:

```
canDrink :: Pred Person
canDrink = isTheBoss `<?>` (hasValidId `<&>` isOldEnough `<&>` not' isDrunk)
```

While the higher kinded typeclasses of *Functors* and *Applicatives* are a more natural fit for functions, it is always satisfying to see that the same thing can be approached from different directions.

# Postscript:

The (more obvious) Applicative solution:

Like with Monoids, it is helpful to remind ourselves of the Applicative and Functor instances for `(->)`

, the type of functions, here with the specialised signatures added for clarity, and reminding ourselves that `(->)`

is written in infix notation, so that `(->) a b`

and `a -> b`

are equivalent:

```
instance Functor ((->) a) where
fmap :: (b -> c) -> (a -> b) -> (a -> c)
fmap f g = f . g
instance Applicative ((->) a) where
pure :: b -> (a -> b)
pure = const
(<*>) :: (a -> b -> c) -> (a -> b) -> (a -> c)
f <*> g = \x -> f x (g x)
```

While we don't see our `andP`

here just yet, it is worth remembering that the type of `pure (&&) <*> isOldEnough`

would be:

```
(Person -> (Bool -> Bool -> Bool)) -> (Person -> Bool) -> Person -> Bool -> Bool
```

and if we have a `Person -> Bool -> Bool`

, we can use use `<*>`

again on a second predicate:

```
let appAnd = pure (&&)
isOlderAnd = appAnd <*> isOldEnough
in isOlderAnd <*> (not . isDrunk)
```

or, more simply (and making use of `<$>`

, the infix synonym for `fmap`

:

```
(&&) <$> isOldEnough <*> (not . isDrunk)
```

When all the infix operators start making your eyes bleed, we can use `liftA2`

from the *Applicative* class, which does exactly this:

```
liftA2 (&&) isOldEnough (not . isDrunk)
```

which means (if we can be bothered considering how trivial this is), we can define `(<&>) = liftA2 (&&)`

## Top comments (0)