So, cats-effect has Resource. It’s nice. Some cats-effect users are considering making a Resource fanclub. Why? Well, probably because of some neat things you can do with it, and two exercises here are to help you see what can be done outside of just flat-mapping some library ones and using them in the end.

These exercises are harder than previous ones. To make matters worse, I also now require using cats-effect typeclasses instead of choosing a concrete F. You can test it with the effect of your choice, of course, but it must work for everything.

On a positive note, I’ve provided scastie links with test cases that I used myself - it is not enough to find all possible bugs, but should get you started quickly and check more edge cases than my previous ones.

Tearing resources apart

There’s one unsafe method on Resource, and it’s called allocated. It gives you access to allocator and finalizer directly. In fact, originally Resource didn’t have it - that’s how dangerous it is. However, it is required for some advanced usages, like embedding a Resource into some other datastructure.

Have you ever used the <*> operator from Apply typeclass, except just to try to understand it? It’s much more common to use, and even explain applicative functors via a syntax sugar on tuples, i.e. (fa, fb).mapN { (a, b) => ??? }. The “double shark” is designed to utilize Haskell’s strengths - always curried functions and Hindley-Milner type inference, which Scala does not have, making use of <*> require quite a bit of ceremony:

f <$> e1 <*> e2 <*> e3

vs.

// Trying to imitate Haskell
{ f[A, B, C](_, _, _) }.curried.pure[F] <*> e1 <*> e2 <*> e3
// Not doing it
(e1, e2, e3).mapN(f)

It’s evident that there are cases - and probably most of such cases - where version playing to Scala strengths requires both less reading/writing and can utilize inference better. But there’s at least one scenario where I’d use the other style, if I could, and that is…

Concurrent data structures

When I fully bought into cats-effect and started using fs2 heavily, lots of my classes began having constructors that look like this:

class StatefulObject[F[_], A, B] (
  pending: Ref[F, Map[B, Deferred[F, NonEmptyList[A]]]],
  updates: Topic[F, Option[(B, NonEmptyList[A])]],
  mutex: MVar[F, Unit]
) { ... }

A short post, for a change.

cats-effect has start. And start has a problem that is outlined right in its docs (link):

* {{{
*   def par2[A, B](ioa: IO[A], iob: IO[B]): IO[(A, B)] =
*     for {
*       fa <- ioa.start
*       fb <- iob.start
*        a <- fa.join
*        b <- fb.join
*     } yield (a, b)
* }}}
*
* Note in such a case usage of `parMapN` (via `cats.Parallel`) is
* still recommended because of behavior on error and cancellation —
* consider in the example above what would happen if the first task
* finishes in error. In that case the second task doesn't get canceled,
* which creates a potential memory leak.

That doesn’t quite feel right. Especially in presense of cancelable flatMaps, it’s possible that we end up with a more ugly situation

Surprisingly not mentioned often, there’s Typelevel kittens, a library for typeclass derivation for Cats, which also has few extra things. In particular, there’s an ability to sequence and traverse an HList. It doesn’t get enough exposure though, so let’s explore few illustrative ways this can be used.

WARNING: This post will contain a lot of code. Crazy shapeless aux type-level computation kind of code.

There’s a lot of info on cats-effect these days, but a lot of it is about concrete use-cases. Yet there’s not much for those who know the basics but don’t feel confident enough with the library to build full-fledged applications. I’ve seen a couple of questions, however, which can be well generalized and are more complex and interesting than examples provided in documentation. So, I decided to turn them into exercises.

If you know how to do FP in Scala, and a bit about cats and cats-effect, the initial solution shouldn’t take more than an hour for you to arrive at. If you struggle to find a solution, there will be a couple of hints. And for those who want to dive deeper, there are bonus assignments which require additional generalization and/or refactoring.

Currently, there are just two. I plan to slowly build up the list as I solve more interesting problems, mine or others’.

Cats-effect 1.0.0-RC2 is out, and among various improvements, it brought to us some goodies in cats.effect.concurrent, exported from fs2 and Monix with a number of changes:

• Ref - pure mutable reference
• Deferred - a purely functional alternative to Promise
• Semaphore - an access control tool
• MVar - a mutable location that can be empty, useful as synchronization and communication channel

This post will focus on Ref and to show what interesting techniques it enables.

Problem:

I want to figure out which log entries belong to which request.

Also, being a lazy person, I want to get away with as little work as possible. In particular that means:

• I don’t want to pass extra function parameters / implicits (solutions like Logger.takingImplicit of scala-logging won’t cut)
• I don’t want to pollute my domain signatures with something like ReaderT[Task, RequestId, A] instead of plain Tasks.
• I don’t want to manually insert request ID to every call to log function. I want to set it once and be done with it.

Java SLF4J API already support all this functionality in form of MDC. However, the existing implementations use a ThreadLocal variable, which doesn’t work if you’re not creating a separate thread per each request - which I do not.

Solution: