How To Use Applicatives For Validation In Scala And Save Much Work

In this post we will see how applicatives can be used for validation in Scala. It is an elegant approach. Especially when compared to an object-oriented way.

Usually when we have operations that can fail, we have them return types like Option or Try. We sequence operations and once there is an error the computation is short circuited and the result is a None or a Failure.

Applicatives allow us to compose independent operations and evaluate each one. Even if an intermediate evaluation fails. This allows us to collect error messages instead of returning only the first error that occurred.

A classic example where this is useful is the validation of user input. We would like to return a list of all invalid inputs rather than aborting the evaluation after the first error.

Scala Cats provides a type that does exactly that. So let’s dive into some code and see how it works.

Continue reading →

Parsers in Scala built upon existing abstractions

After some initial struggles, the chapter Functional Parsers from the great book Programming in Haskell by Graham Hutton, where a basic parser library is built from scratch, significantly helped me to finally understand the core ideas of parser combinators and how to apply them to other programming languages other than Haskell as well.

While I recently revisited the material and started to port the examples to Scala I wasn’t able to define a proper monad instance for the type Parser[A].

The type Parser[A] alias was defined like this:

type Parser[A] = String => Option[(A, String)]
// defined type alias Parser

To test the monad laws with discipline I had to provide an instance of Eq[Parser[A]]. Because Parser[A] is a function, equality could only be approximated by showing degrees of function equivalence, which is not a trivial task.

Also the implementation of tailRecM was challenging. (I couldn’t figure it out.)

Using existing abstractions

Continue reading →

Strongly Typed Configuration Access With Code Generation

Most config libraries use a stringly typed approach.

Some handle runtime failures due to invalid configuration schemas by leveraging data types like Option or Result to represent missing values or errors. This allows us to handle these failures by either providing default values or by providing decent error messages.

This is a good strategy that we should definitely stick to.

However, the problem with default values is that we might not even notice if the configuration is broken. This could potentially fail in production. In any case an error e.g. due to a misspelled config property will be observable at runtime at the earliest.

Wouldn’t it be a great user experience (for us developers) if the compiler told us if the configuration schema is invalid? Even better, imagine we could access the configuration data in a strongly typed way like any other data structure, and with autocompletion.

Moreover, what if we didn’t have to write any glue code, not even when the configuration schema changes?

This can be done with the costs of an initial setup that won’t take more than probably around 5 minutes.

Continue reading →

Error and state handling with monad transformers in Scala

In this post I will look at a practical example where the combined application (through monad transformers) of the state monad and the either monad can be very useful.

I won’t go into much theory, but instead demonstrate the problem and then slowly build it up to resolve it.

You don’t have to be completely familiar with all the concepts as the examples will be easy to follow. Here is a very brief overview:

Continue reading →

Use lambdas and combinators to improve your API

If your API overflows with Boolean parameters, this is usually a bad smell.

Consider the following function call for example:

toContactInfoList(csv, true, true)

When looking at this snippet of code it is not very clear what kind of effect the two Boolean parameters will have exactly. In fact, we would probably be without a clue.

We have to inspect the documentation or at least the parameter names of the function declaration to get a better idea. But still, this doesn’t solve all of our problems.

The more Boolean parameters there are, the easier it will be for the caller to mix them up. We have to be very careful.

Moreover, functions with Boolean parameters must have conditional logic like if or case statements inside. With a growing number of conditional statements, the number of possible execution paths will grow exponentially. It will become more difficult to reason about the implementation code.

Can we do better?

Sure we can. Lambdas and combinators come to the rescue and I’m going to show this with a simple example, a refactoring of the function from above.

This post is based on a great article by John A De Goes, Destroy All Ifs — A Perspective from Functional Programming.

I’m going to take John’s ideas that he backed up with PureScript examples and present how the same thing can be elegantly achieved in Scala.

Continue reading →

Modelling API Responses With sbt-json – Print Current Bitcoin Price

I’m currently working on an sbt plugin that generates Scala case classes at compile time to model JSON API responses for easy deserialization especially with the Scala play-json library.

The plugin makes it possible to access JSON documents in a statically typed way including auto-completion. It takes a sample JSON document as input (either from a file or a URL) and generates Scala types that can be used to read data with the same structure.

Let’s look at a basic example, an app that prints the current Bitcoin price to the console.

Continue reading →

A new Scala feature for making illegal states unrepresentable

Making illegal states unrepresentable means that we enforce invariants on the code that we write, and choose data types so that states that are invalid won’t show up in our programs. 1

By reducing the number of representable wrong states we also reduce the number of potential bugs in our program by a great deal, as well as the number of tests needed to check for invalid inputs and outputs.

If we can’t create an illegal argument of a given type, we don’t need test cases for this illegal state for any function that takes arguments of that type as inputs.

Continue reading →

12 Things You Should Know About Event Sourcing

Are you aware that storing and updating current state means loosing important data?

Event sourcing is a way to solve this problem. It is the technique of storing state transitions rather than updating the current state itself.

Event sourcing has some more benefits:

  • Complete audit-proof log for free
  • Complete history of every state change ever
  • No more mapping objects to tables
  • Distribution support
  • CQRS (Command Query Responsibility Segregation) support
  • Natural fit for domain-driven design and functional programming
  • Be prepared for unanticipated use cases in the future (for free)

State transitions are an important part of our problem space and should be modelled within our domain — Greg Young

When I first encountered the concept of event sourcing and CQRS and looked at some sample applications, I had the impression that it must be extremely difficult to implement. But later I found out that event sourcing is easier than I first thought, especially when it is expressed with functional programming.

Here are 12 things about event sourcing that should help you to get started today.

Continue reading →

What are Scala Type Classes?

What are Scala type classes, what kind of problem do they solve and how are they implemented?

In a nut shell, type classes provide polymorphism without using subtyping, but in a completely type safe way.

Type classes represent some common functionality that can be applied to values of many different types. Moreover, we don’t have to change existing types in order to extend them with the new functionality.

In this post I will describe 5 simple steps for encoding a type class in Scala in an idiomatic way.

Continue reading →

7 Most Convenient Ways To Create A Future Either Stack

In Scala Future[A] and Either[A, B] are very useful and commonly used types. Very often we want to combine them, but a Future[Either[A, B]] is kind of awkward to handle not only because we don’t want to have to call Await anywhere.

One way to deal with this is to stack the types into a combined data type EitherT defined in Cats that is much easier to handle.

Still it can be quite unwieldy to compose values of this new type with other values of different types.

To get nice composability (e.g. with for comprehensions) we have to wrap other values into the new type by lifting them up inside the monad stack.

Here are the most convenient ways that I found to do that.
Continue reading →