Our thoughts, knowledge, insights and opinions

In this post we will continue our adventure with shapeless and demonstrate how it can be used to make your code more compact and flexible.

by
Tomasz Perek

October 22, 2015

Tags :
Scala
Shapeless
Futures
Type-level programming

In my previous blog post we talked about shapeless and how it could be applied to enhance how you work with `Futures`

. Even though we were focused on `Future`

s, our goal wasn’t to provide the best and ultimate util to deal with them, but to demonstrate how shapeless can help us build functions that are more flexible than almost everything we are used to work with. So in last post we have created a kind of varargs function that is able to adjust its return type to the arguments passed in. Today we’ll take it much farther by adding scalaz, `ApplicativeBuilder`

and `Monad`

s into the soup.

Yes, Scalaz, Applicative Builder… Scalaz is library that, to quote the definition the authors have given, “*provides purely functional data structures to complement those from the Scala standard library. It defines a set of foundational type classes (e.g. Functor, Monad) and corresponding instances for a large number of data structures*”. Most people associate it with cryptic operators to work with these “purely functional data structures”: `|@|`

(so called Macaulay Culkin), `<*>`

, `<|`

etc. and it’s what scares the hell out of many people.
I find it unfair. In fact, scalaz provides many very useful utils (some of which are actually very basic), type classes and other concepts and I highly encourage you to get familiar with it. This is probably one of the best training resources on the web. We won’t even try to walk through every aspect of it (is there even a man who would be able to do it?). I’m mentioning it, because some people pointed out that the same or similar effect could be obtained using scalaz’s `ApplicativeBuilder`

pattern. This is an excerpt from comment by @caente (an engineer at x.ai, a blogger and a guy always willing to help:) ) aiming to support this opinion:
Well, my answer for this claim is “yes, but no” :) It’s not exactly the same thing, and it’s more verbose from one point of view, yet more flexible from the other, as it allows you to apply a function right away. Important thing is that this comment actually gave me an idea for this post. We’ll focus on `ApplicativeBuilder`

to prove some thesis.

So here’s the thesis: *With shapeless you can create code, that is much more flexible, and much more compact than it would be if you didn’t use shapeless*. It won’t introduce new design patterns or paradigms nor will make any old ones obsolete, yet there will be big benefit in much less lines of code and much bigger flexibility. In order to advocate for this thesis we will try to implement our own version of `ApplicativeBuilder`

Before we start, let’s say what’s wrong with the code from last post. It’s only for `Futures`

. The advantage `ApplicativeBuilder`

has over our `hsequence`

/ `zip`

functions is that it works with any class belonging to `Applicative`

type class. So it will work with `Option`

s, `List`

s and `Future`

s, while `zip`

is only for `Future`

s. So let’s remove this constraint.

Our base trait will now look as follows:
What has changed? Besides the name, which now reflects that the code is no longer intended to work only with `Future`

s, the trait has one more type parameter, `M[_]`

, a type constructor. Also the return value of `hsequence`

method has changed from `Future[Out]`

to `M[Out]`

. Let’s ignore `ToMonadOps`

for a while. It’s an useful tool providing implicit conversions for instances of M, but these details aren’t needed in this discussion.
Now, as a base case, implementation for `HNil`

:

First of all, since `object`

s can’t have type parameters, we must use `def`

, but that’s not a big deal. The other thing new is evidence `m: Monad[M]`

. This puts a constraint on `M`

, we want it to belong to `Monad`

type class. Why `Monad`

? It’s because we need access to `bind`

, `pure`

, and `map`

functions. That’s making our life a bit easier, as original `ApplicativeBuilder`

works with `Applicative`

s, but not having access to `flatMap`

would disperse our focus. In the code above we use `m.pure(HNil)`

to construct `M[HNil]`

. We couldn’t use constructor, because we simply don’t know what exact type `M`

will be.

What about longer `HList`

s? Here’s the code:

It’s getting a bit crowded in type parameters section, and in implicit params too, but there’s only one new thing: `M[_]`

parameter and evidence that it is a `Monad`

. The implementation of `hsequence`

isn’t really that much different from what we had for `Future`

s. We use `flatMap`

(again, that’s why we needed `M`

to be a `Monad`

, not just `Applicative`

) and `map`

just as we had with `Future`

s. Let’s put it together:
All in all it’s just a little bit different than it was before. The same goes for implementations of `hsequence`

and `zip`

functions. We are introducing one more type parameter, `M[_]`

and providing one more evidence, that `M`

is a `Monad`

:
But now we won’t be limited to `Futures`

, as following `ScalaTest`

spec shows:
It may be a bit surprising how it works with `List`

s, but’s exactly the same as if you used `|@|`

from scalaz.
One challenge solved, we have our `zip`

/`hsequence`

working with everything that belongs to `Monad`

type class.

We are now just one step away from giving life to our own `ApplicativeBuilder`

. But before we do it, let’s recall what it actually is. It’s a trait, that allows you to combine `Applicative`

s using `|@|`

operator and then either return tuple with combined applicative or execute some function on it, just as it was demonstrated in @caente’s comment. Now, why are we reimplementing it?. This is why:
its implementation. The code is ~170 lines long and it’s a pyramid that is just begging to be simplified. You have just one mean to do it, and it’s type-level programming. I won’t make you wait any longer - here’s the code:
We just only need an `implicit def`

to convert `Monad`

s to single-element `ScalacApplicativeBuilder`

:
and that’s actually it.

How does it work? First important thing is that it maintains a `HList`

of `Monad`

s in `values`

field. Method `:@:`

just adds one more item this list. `asTuple`

is calling our old friend `hsequece`

on values and turns the result into `Tuple`

. `apply`

transforms given function argument into `HList`

equivalent and then maps results of `hsequence`

with that equivalent. All these ‘shapeless magic tricks’ are nothing new, as they were discussed in our last post. And that’s that, there’s nothing else.

Now, did we prove our thesis? Together with imports, the full and standalone implementation of our `ScalacApplicativeBuilder`

is only 42 lines long:
It allows doing the same things as original Applicative Builder and is not limited to 12 elements. Let’s just take a quick look on specs:
As we can see, we can do what we could with original `ApplicativeBuilder`

and more.

So in my humble opinion that’s a **Q.E.D.** :) I hope you enjoyed reading this post as much as I did writing it, but what I hope even more, is that I have managed to convince at least some people to look kindly on shapeless.

Thank you!

by
Tomasz Perek

October 22, 2015

Tags :
Scala
Shapeless
Futures
Type-level programming