3. February 20204. February 2020 by Leif

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 →

26. January 202026. January 2020 by Leif

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 →

8. August 20198. August 2019 by Leif

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 →

29. April 20181. May 2018 by Leif

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 →

10. March 201810. March 2018 by Leif

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 →

3. February 201823. February 2018 by Leif

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 →

22. December 201722. December 2017 by Leif

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 →

8. October 20178. October 2017 by Leif

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 →

5. September 20176. September 2017 by Leif

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 →

17. August 201727. August 2017 by Leif

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 →

In the previous posts of this series we have seen how functional error handling can be implemented in F# and C#.

Now let's look at an implementation of the command line parser using the Notification Pattern.

Parsing arguments with the Notification Pattern

All the dependencies, in this case the arguments and the argument infos, are provided as constructor parameters.

The class exposes a public read-only property Dictionary which has a private backing field. In the getter the dictionary will be created if the backing field is NULL. If the creation of the dictionary fails, an exception will be thrown.

The caller can check if the arguments are valid by calling the Validation method. This method will return a Notification instance which is a container for error messages. The Notification instance has a property IsValid that is true if the validation succeeded, otherwise it is false.

Here is a shortened version of the class:

public class NoteArguments
{
    private readonly IEnumerable<string> _commandLineArguments;
    private readonly IEnumerable<string> _requiredCommands;
    private readonly IEnumerable<string> _definedCommands;
    private Dictionary<string, string> _dictionary;

    public NoteArguments(IEnumerable<string> commandLineArguments, IEnumerable<ArgInfo> defs)
    {
        _commandLineArguments = commandLineArguments;
        _requiredCommands = defs.Where(x => x.required).Select(x => x.command);
        _definedCommands = defs.Select(x => x.command);
    }

    public Dictionary<string, string> Dictionary
    {
        get
        {
            return _dictionary ?? (_dictionary = CreateDictionary());
        }
    }

    private Dictionary<string, string> CreateDictionary()
    {
        Check();
        return _dictionary;
    }

    private void Check()
    {
        var note = Validation();
        if (note.HasErrors)
            throw new ArgumentException(note.ErrorMessage);
    }

    public Notification Validation()
    {
        var note = new Notification();

        var parsed = Parse(note);

        if (note.HasErrors)
            return note;

        CheckNoDuplicates(parsed, note);
        CheckAllRequired(parsed, note);
        CheckAllDefined(parsed, note);

        if (note.IsValid)
            _dictionary = parsed.ToDictionary(x => x.First(), x => x.Skip(1).First());

        return note;
    }
    //... 
}

There are numerous other possibilities of how to implement this class and its public interface depending on the context. Returning a Notification instance might not really be necessary because in this case there is no separated presentation layer. So the IsValid or Errors properties and the Validate method could be members of the NoteArguments class itself. Or we could also implement an interface IValidatable<T> which exposes those members. Also the validator could be injected. However, since all implementations are in essence very similar I tried to stick with a very basic approach for demonstration purposes.

It's easy to shoot yourself in the foot

So what is the drawback of this design?

This design makes it very easy to shoot yourself in the foot.

If we access the Dictionary property while the provided command line parameters are not valid, the application will crash.

Can we avoid this? - No, we can't avoid this because we don't know what to return in case of a failure. Off course we could return NULL or even a NULL object, but this only postpones the need to handle the failure case. The call side has to wrap the calling code into a try-catch statement or check for null.

And the real problem with this is that the caller is not forced to do that. Also it might not even be obvious for the caller that accessing a given property could crash the application. Furthermore, exceptions, try-catch statements, and NULL checks will decrease the readability and maintainability of the code and will ruin the possibility to reason about the code.

> @davetchepak "What can C# do that F# cannot?" NullReferenceException 🙂

— Tomas Petricek (@tomaspetricek) 21. März 2013

Exceptions and expected behavior

Martin Fowler states that exception are only for unexpected behaviors:

Exceptions signal something outside the expected bounds of behavior of the code in question. But if you're running some checks on outside input, this is because you expect some messages to fail - and if a failure is expected behavior, then you shouldn't be using exceptions. -- Martin Fowler

And still the notification pattern uses exceptions for an expected failure case. As we have seen, we can not really avoid an exception when accessing the Dictionary property while the provided command line parameters are not valid. But this is not an unexpected situation because the command line parameters are outside inputs, so it is not unlikely that something goes wrong.

A better way of doing error handling

Returning NULL or a NULL object goes into the right direction, even though that's still far away from a good and solid design.

If we continue to think this approach we will eventually end up with the idea of the Result type as implemented by the Chessie library. The details of this approach are described in the first three parts of this series.

By comparing the functional error handling approach to the imperative approach it will become even more clear what the benefits of the Result type are.

Because it is very hard and inconvenient to extract the inner value of a Result without using its provided methods, the caller is always forced to handle the success as well as the failure case. There is no need to throw exceptions or to return NULL. Therefore the code won't be cluttered with try catch statements or NULL checks. Instead the caller can use the composition mechanisms of functional error handling which is applicative and monadic composition. As a result the code will be more declarative. The composition mechanisms will always be the same and they scale through all the layers of the application.

The FsCQRSShop and Railway-Oriented-Programming-Example are only two examples that demonstrate functional error handling and railway oriented programming without any exceptions where the data flows on two tracks throughout the application.

Conclusion

In the first three posts of this series we have examined the details of functional error handling with the help of the library Chessie in F# and C#. In C#, though, functional error handling is not as comfortable as it is in F# because of missing language features. Additionally, the possibility to initialize a Result value with NULL in C# ruins the benefit of safety that we have in F#. But still if C# and F# projects have to inter-operate, it does work fine with the Chessie library.

In this post we briefly compared the functional to the imperative approach.

We have seen the benefits of functional error handling, which are:

A much safer and solid usage
More predictable code
The details of error handling are abstracted away
More declarative code
Functional error handling embraces composition, separation of concerns and scalability

Leif Battermann

Functional Programming Fu

Identify Side Effects And Refactor Fearlessly

Why avoid side effects?

PureScript Case Study And Guide For Newcomers

Elm And The Algorithm Of Music

From a music data type to performance

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

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

Parsers in Scala built upon existing abstractions

Using existing abstractions

Strongly Typed Configuration Access With Code Generation

Error and state handling with monad transformers in Scala

Use lambdas and combinators to improve your API

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

Leif Battermann

Functional Programming Fu

Functional vs. imperative error handling

Parsing arguments with the Notification Pattern

It's easy to shoot yourself in the foot

Exceptions and expected behavior

A better way of doing error handling

Conclusion

Resources