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
Futures, 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,
Monads 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
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
zip functions is that it works with any class belonging to
Applicative type class. So it will work with
zip is only for
Futures. 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
Futures, the trait has one more type parameter,
M[_], a type constructor. Also the return value of
hsequence method has changed from
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
First of all, since
objects 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
map functions. That’s making our life a bit easier, as original
ApplicativeBuilder works with
Applicatives, 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
HLists? 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
Futures. We use
flatMap (again, that’s why we needed
M to be a
Monad, not just
map just as we had with
Futures. 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
zip functions. We are introducing one more type parameter,
M[_] and providing one more evidence, that
M is a
But now we won’t be limited to
Futures, as following
ScalaTest spec shows:
It may be a bit surprising how it works with
Lists, but’s exactly the same as if you used
|@| from scalaz.
One challenge solved, we have our
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
|@| 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
Monads to single-element
and that’s actually it.
How does it work? First important thing is that it maintains a
values field. Method
:@: just adds one more item this list.
asTuple is calling our old friend
hsequece on values and turns the result into
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.