Identify Side Effects And Refactor Fearlessly

When we refactor code how can we be confident that we don't break anything?

3 of the most important things that allow us to refactor fearlessly are:

  • Side effect free - or pure - expressions
  • Statically typed expressions
  • Tests

In this article we will solely focus on the aspect of side effects and strictly speaking on how to identify them. Being able to identify side effects in our programs clearly is the precondition for eliminating them.

Why avoid side effects?

Continue reading →

PureScript Case Study And Guide For Newcomers

Have you ever wanted to try out PureScript but were lacking a good way to get started?

If you

  • Have some prior functional programming knowledge - maybe you know Haskell,Elm,F#,or Scala,etc.
  • Want to solve a small task with PureScript
  • And want to get started quickly

This post is for you!

In this post we will walk through setting up and implementing a small exemplary PureScript application from scratch.

Continue reading →

Elm And The Algorithm Of Music

In this article I would like to present a minimal implementation of a music data type and everything that is needed to turn that into audible sound from an Elm application.

We will see how to transcribe an existing composition - an excerpt from Chick Corea's Children's Songs No. 6 - and listen to the result right here,embedded in this article.

From a music data type to performance

My colleague Jonas recently pointed out the presentation Making Algorithmic Music by Donya Quick to me. Donya Quick shows how she uses the Haskell library Euterpea to produce algorithmic music.

It got me really excited about the idea of porting this to Elm and to be able to use this in web applications.

In the following we will see the core data types and algorithms from Euterpea ported to Elm. To focus on the core concepts the implementation is stripped down to the minimum that is required to transcribe and perform an existing polyphonic piece of music (for a single instrument).

Continue reading →

Interactive Command Line Applications In Scala –Well Structured And Purely Functional

This post is about how to implement well structured,and purely functional command line applications in Scala using PureApp.

PureApp originated in an experiment while refactoring out some glue code of an interactive command line application. At the same time it was inspired by the Elm Architecture Pattern,and scalaz's SafeApp,as well as scalm.

To show the really cool things we can do with PureApp,we will implement a self-contained example application from scratch.

This application translates texts from and into different languages. And it provides basic user interactions via the command line.

The complete source code is compiled with tut. Every output (displayed as code comments) is generated by tut.
Continue reading →

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:


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 →

'|Droid+Sans+Mono|Open+Sans:400,600,700';.elm-music-play-button,.elm-music-stop-button{margin:2px;}span.n{color:#96C71D;}table.pre,pre.fssnip,pre{line-height:13pt;border:1px solid #d8d8d8;border-collapse:separate;white-space:pre;font:9pt'Droid Sans Mono',consolas,monospace;width:90%;margin:10px 20px 20px;background-color:#212d30;padding:10px;border-radius:5px;color:#d1d1d1;max-width:none;}.shariff{display:block !important;clear:both}.shariff ul{display:flex;flex-direction:row;flex-flow:row wrap;padding:0 !important;margin:0 !important}.shariff li{height:35px;box-sizing:border-box;list-style:none !important;overflow:hidden !important;margin:5px !important;padding:0 !important;text-indent:0 !important;border-left:0 none !important}.shariff a{position:relative;display:block !important;height:35px;padding:0;margin:0;box-sizing:border-box;border:0;text-decoration:none;background-image:none !important;text-align:left;box-shadow:none;cursor:pointer}.shariff .shariff-icon svg{width:32px;height:20px;padding:7px 1px;box-sizing:content-box !important}.shariff-button::before{content:none !important}.shariff .shariff-buttons.theme-round li{width:35px !important;height:35px;border-radius:50%;margin:5px}.shariff .theme-round a{position:relative;height:35px;border-radius:50%}.shariff .theme-round .shariff-icon svg{display:block;margin:auto;padding:8px 1px}.shariff .theme-round .shariff-icon svg path{fill:#fff}.shariff.shariff-align-flex-start ul{justify-content:flex-start;align-items:flex-start}.widget .shariff.shariff-widget-align-flex-start ul{justify-content:flex-start;align-items:flex-start}.widget .shariff li{border:0;font-weight:400}.widget .shariff .theme-default a,.widget .shariff .theme-color a,.widget .shariff .theme-grey a,.widget .shariff .theme-round a{color:#fff;display:block;font-weight:400}@media only screen and (max-width:360px){.shariff .shariff-buttons li{width:35px}.shariff .shariff-buttons .shariff-icon svg{display:block;margin:auto}}@media only screen and (min-width:361px){.shariff .shariff-buttons li{width:125px}}@media screen{@font-face{font-family:'FontAwesome';src:url(/wp-content/themes/editor/inc/fontawesome/fontawesome-webfont.eot);src:url(/wp-content/themes/editor/inc/fontawesome/fontawesome-webfont.eot) format('embedded-opentype'),url(/wp-content/themes/editor/inc/fontawesome/fontawesome-webfont.woff) format('woff'),url(/wp-content/themes/editor/inc/fontawesome/fontawesome-webfont.ttf) format('truetype'),url(/wp-content/themes/editor/inc/fontawesome/fontawesome-webfont.svg) format('svg');font-weight:normal;font-style:normal;}.fa{display:inline-block;font-family:FontAwesome;font-style:normal;font-weight:normal;line-height:1;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;}@-moz-keyframes spin{0%{-moz-transform:rotate(0deg);}100%{-moz-transform:rotate(359deg);}}@-webkit-keyframes spin{0%{-webkit-transform:rotate(0deg);}100%{-webkit-transform:rotate(359deg);}}@-o-keyframes spin{0%{-o-transform:rotate(0deg);}100%{-o-transform:rotate(359deg);}}@keyframes spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg);}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg);}}.fa-times:before{content: "\f00d";}.fa-folder:before{content: "\f07b";}.fa-folder-open:before{content: "\f07c";}.fa-navicon:before,.fa-reorder:before,.fa-bars:before{content: "\f0c9";}#simple-social-icons-2 ul li a,#simple-social-icons-2 ul li a:hover,#simple-social-icons-2 ul li a:focus{background-color:#999 !important;border-radius:3px;color:#fff !important;border:0px #fff solid !important;font-size:18px;padding:9px;}}

Functional error handling in F# by example

Exceptions are bad.

Not only do we have to remember to catch them everywhere, they also provide a second implicit exit strategy for functions, similar to the goto statement.

However, there is an alternative more explicit approach.

In this post we will go through an example of how to implement decent functional error handling in F# without using NULL or exceptions.

We will do this by extending the application from the last post and make it even more reliable and robust.

The traditional way

Traditionally, failures are handled by either returning NULL, a special value (such as "", -1 or a NULL object), or by raising exceptions.

One of the problems with these approaches is that the caller always has to remember to do a thing. Furthermore the caller has, in general, no way of knowing whether a function might fail or not by only looking at its signature.

And there are more pitfalls (see Domain-Driven Design (DDD) With F# - Validation).

Representing potential failures with types

Most functional programming languages including F# have special types that can represent optional or missing values for example the Option type. A function that returns an Option<'a>, indicates that it might succeed and return Some<'a>, or that it might fail and return None.

The success and the failure case are explicitly represented by the type system.

The type system will check for us that we handle both cases when calling a function that returns an optional value. We don't have to remember to do so. If we forget, the compiler will remind us because the application won't compile!

It is impossible to overemphasize how valuable that is.

The Chessie project

In this post we will use the Result type which is slightly more advanced than Option.

A Result is defined like this:

type Result<'TSuccess, 'TMessage> = 
    | Ok of 'TSuccess * 'TMessage list
    | Bad of 'TMessage list

The advantage of the Result type is that it let's us define error messages that we can return in case of failures. Furthermore we don't have to hand-roll the generic error handling code.

Instead we can use the Chessie library which offers this type together with a very useful set of operations.

Implementing error handling and validation with the Result type is also sometimes called Railway Oriented Programming.

Note that there are a few other possibilities besides Chessie. There is the validation framework of Fsharpx.Extras or we could use ExtCore. There are also considerations to include the Result type into the F# language.

Extending an existing application

Here is the code of the application that we are going to extend. It is a very basic command line tool to manage the import of email addresses from a CSV file into a database. The little program is explained in more detail here. But the code is almost self-explanatory.

The application has 3 kinds of operations that could potentially fail:

  • Updating a database
  • Reading from a file (CSV and CONFIG files)
  • Parsing command line arguments

Line of action

To improve the application with decent error handling we need to take these 3 basic steps:

  • Define an appropriate message type
  • Make the failure cases explicit
  • Update the integration code

Before we begin we have to add a reference to Chessie for example by installing it from NuGet and add the import declaration open Chessie.ErrorHandling.

Defining an appropriate message type

There are many possibilities to define a type that represents a failure, or more general, a domain message.

In general the DomainMessage type should contain enough information to:

  • Display adequate and user-friendly error messages
  • Log everything needed for a detailed error analysis

Here is one possible definition:

type DomainMessage = 
    | DbUpdateFailure of Exception
    | CsvFileAccessFailure of Exception
    | CliArgumentParsingFailure of Exception
    | ConfigurationFailure of Exception

The DomainMessage type is defined as a discriminated union with one case for each of the general types of failures mentioned above.

In some of these cases there are more sub-types of possible failures. For example, when updating the database we could get an Invalid column name, a violation of primary key or some other error.

Note that each union case holds a value of type Exception. This makes sense in this scenario. However, we can use any kind of value (or combination of values) that suits our needs.

Making the failure cases explicit

Changing the implementations of the unsafe functions is quite easy.

We will just wrap all the code that accesses external data sources in try catch statements.

If an exception is caught, we will return a DomainMessage wrapped in a Bad case of the Result type. Otherwise we will return the result value wrapped in the Ok case.

As this strategy is always the same, we will create a higher-order function to reduce code duplication:

// val tryF : f:(unit -> 'a) -> msg:(exn -> 'b) -> Result<'a,'b>
let tryF f msg =
    try f() |> ok with ex -> fail (msg ex)

In the beginning I stated that throwing exceptions is bad. However, if it is an external library that is throwing exceptions we cannot help, but handle them as close as possible to where they occur.

Here is one example

We will only look at one example because it will always be the same.

This was the original code for reading from the CSV file:

// val readFromCsvFile : fileName:string -> MailingListEntry list
let readFromCsvFile (fileName:string) = 
    let data = MailingListData.Load(fileName)
    [for row in data.Rows do
        yield { Email = Email row.Email; Name = Name row.Name}]

Here is the new version:

// val readFromCsvFile : fileName:string -> Result<MailingListEntry list,DomainMessage>
let readFromCsvFile (fileName:string) = 
    let read () =
        let data = MailingListData.Load(fileName)
        [for row in data.Rows do
            yield { Email = Email row.Email; Name = Name row.Name}]
    tryF read CsvFileAccessFailure

The signature of readFromCsvFile now looks like this:

val readFromCsvFile : fileName:string -> Result<MailingListEntry list,DomainMessage>

That means if the operation succeeds, the function will return a list of MailingListEntry. Otherwise it will return a DomainMessage.

Likewise we will change all the other functions...

The database accessing functions in the module DataAccess will now have these signatures:

val insert : cs:string -> list:MailingListEntry list -> Result<unit,DomainMessage>

val delete : cs:string -> Result<unit,DomainMessage>

The function that parses the command line arguments in the module Arguments will have this signature:

val getCmds : args:string [] -> Result<CliArguments list,DomainMessage>

To retrieve the connection string from the configuration file we will just directly bind the result to the value csResult of type Result<string, DomainMessage> like this:

// val csResult : Result<string, DomainMessage>
let private csResult =
    tryF (fun () -> Settings.ConnectionStrings.MyMailingListDb) ConfigurationFailure

Updating the integration code

Now we have to put everything together.

Normal function application won't work anymore because the types have changed and don't match.

Therefore we will use the composition mechanisms of the Result type.

In this case we will compose the functions with the bind operator or with >>= (the infix version of bind).

Note that there is also the composition with apply which we won't cover here.

Injecting the connection string

First we have to partially apply the database access functions to the connection string which is wrapped in a Result and bound to csResult:

// val import : list:MailingListEntry list -> Result<unit,DomainMessage>
let import list = csResult >>= fun cs -> DataAccess.insert cs list
// val delete : unit -> Result<unit,DomainMessage>
let delete() = csResult >>= DataAccess.delete

Another option would be to use a computation expression. In this case that is the trial computation expression provided by Chessie:

let import list = trial {
    let! connectionString = csResult
    let! result = DataAccess.insert connectionString list
    return result }

The result is the same.

For more information on this particular kind of computation expression please refer to Composition with an Either computation expression.

In cases when the expression is more complex I would prefer the computation expression because it is much more readable. In this case, though, I prefer using the infix bind operator because it is much more concise. I think that computation expressions are more idiomatic in F#, but at the end it's a matter of taste.

Handling a single command

To update the handle function we will only replace the pipe operator |> with the >>= operator:

// val handle : cmd:CliArgument -> Result<unit,DomainMessage>
let handle cmd =
    match cmd with
    | Import fileName -> readFromCsvFile fileName >>= import
    | Delete          -> delete()

I find this quite elegant, in fact. To me this is a soft indication of how sound the concept of functional error handling is.

Processing a list of commands

Next we have to update the function that processes the list of commands.

Original implementation:

// val run : args:string [] -> unit
let run args =
    getCmds args
    |> List.iter handle

This is just a bit more tricky. And there are a few ways to do this.

So let's think about what the return type of our new version should be?

The original implementation of run returns unit which indicates the absence of a specific value. So the return type that we want to achieve is Result<unit, DomainMessage>.

Let's try to map the handle function over the list of CliArguments that is wrapped in a Result with Trial.lift:

getCmds args |> Trial.lift ( handle)

This will return a Result<seq<Result<unit,DomainMessage>>,DomainMessage> which is quite unwieldy, though.

So one possible solution is to use Trial.collect to convert a list of results into a result of a list: handle >> Trial.collect

If at least one of the results is a failure, only errors will be collected and returned.

Now, because this returns a Result<unit list, DomainMessage>, we can use the >>= operator again:

// val run : args:string [] -> Result<unit list,DomainMessage>
let run args =
    getCmds args >>= ( handle >> Trial.collect)

Again there is an explicit version with the trial computation expression:

trial {
    let! cmds = getCmds args
    let! result = cmds |> handle |> Trial.collect
    return result }

Note that both versions return unit list (instead of a single value of type unit) wrapped in a Result. This could be fixed easily. For example we can map ignore over it. However it doesn't make a difference in this particular situation.

When we use Trial.collect we have to be careful about the behavior.

Since handle is not a pure function all side effects of the successful operations will occur even if there are errors and the overall result is a failure.

A different approach

An alternative approach would be to fold over the list of CliArguemtns with bind.

This would also change the behavior.

In the first version all commands will be handled and afterwards the errors will be collected if there are any.

The alternative behavior is to abort the processing as soon as the first error occurs. We can achieve this with a fold:

// val handleMany: args:seq<CliArguments> -> Result<unit,DomainMessage>
let handleMany args = 
    args |> Seq.fold (fun result next -> result >>= fun _ -> handle next) (ok ())

Next we can bind handleMany to the result of getCmds args:

// val run : args:string [] -> Result<unit,DomainMessage>
let run args = getCmds args >>= handleMany

The main method

Finally in the main method we can:

  • Process the command line arguments
  • Pattern match on the result
  • In case of failure(s) display (and log) helpful error messages
let main argv = 
    let result = run argv

    match result with
    | Ok _     -> do printfn "SUCCESS"
    | Bad errs -> do errs |> List.iter handleError

The complete code is available on GitHub .


Traditional error handling has many pitfalls.

The alternative to traditional error handling is functional error handling which represents potential failures explicitly with the type system.

In this post we have seen an example of how to extend an existing application with functional error handling in F#.

The concept, especially the composition part, is not totally easy to understand if you're new to functional programming.

In my opinion, the key to understanding is to try it out and use it. This is why I presented an example rather than explaining too many details.

For more information on the details please refer to Railway Oriented Programming and The "Map and Bind and Apply, Oh my!" series.

Another tutorial with examples in F# and C# you can find here: Error handling with Applicative Functors in F# and C#.

Once you get a hang of it, you'll love it. I promise!

If you have any questions or comments, please let me know or leave a comment here.