1. Intro

(TODO)

2. Closures

2.1. Definition

Until I find a better definition, I came up with the following "informal" definition:

A closure is a function which allows access to variables declared in its surrounding scope when the closure was declared.

Normally this surrounding scope in Groovy means local variables and non-local variables inside its upper lexical scopes up to class fields.

The minimal version of a closure could be:

Declaring a closure
def closure = { -> }

def closureWithArgs = { arg1, arg2 -> (1)
    println "statements" (2)
}

def closureWithImplicit = {
    println it (3)
}

Closure<?> typedClosure = {-> } (3)
1 A closure may have closure aguments
2 A closure body may have statements
3 A closure may have an implicit variable
4 Closures always return a value (even though it could be void).

Closures can be declared in as class fields, static fields, and local variables.

I’ve included the typed version because sometimes people forgot about the fact that a closure is a function, and like any other function it could return something.

Lets review the principals of a closure:

Using a closure
void 'Declaring and executing a closure'() {
    given: 'a variable and a closure'
        def x = 1 (1)
        def c = { ->
            def y = 1 (2)
            x + y (3)
        }
    when: 'executing the closure'
        def result = c() (4)
    then: 'the value should be the expected'
        result == 2
}
1 A closure can access non-local variables available in upper lexical scopes when the closure was declared
2 A closure can access local variables
3 Has its own execution body
4 Because it is a function, can be executed

Closures may reference variables external to their own definition. This includes local variables, method parameters, and object instance members. However, a closure may only reference those variables that the compiler can lexically deduce from the physical location of the closure definition within the source file.

It’s very important to keep in mind that a closure "sees" those variables available when the closure was declared, not when it’s used.

2.2. Getting started

Closures are widely used in Groovy. One of the most common places are collections. In the following example we want to get 2 times each element of the collection.

Using closures in API
void 'Using closures with collections (I)'() {
    given: 'a collection of numbers'
        def numbers = [1, 2, 3, 4]
    when: 'collecting the double of each of them'
        def doubledNumbers = numbers.collect { it * 2 } (1)
    then:
        doubledNumbers == [2, 4, 6, 8]
}

The collect method receives a parameter of type Closure that transforms every item in the collection.

1 Anonymous closure with implicit variable. In this case the variable refers to every element in the collection.

You can also declare the closure and use it later as a parameter to another function.

Using closures in API
void 'Using closures with collections (II)'() {
    given: 'a collection of numbers'
        def numbers = [1, 2, 3, 4]
    when: 'collecting the double of each of them'
        def collector = { it * 2 } (1)
        def doubledNumbers = numbers.collect(collector) (2)
    then:
        doubledNumbers == [2, 4, 6, 8]
}
1 Declaring the closure
2 Passing closures as parameters to other functions (closures or methods)

2.3. Composition

Sometimes we end with a lot of functions used all over the code, but many times used in different ways, orders…​etc.

Imagine you have a problem and you only know there will be two numbers as an input and the result will be decimal. Your boss tells you to add them up until he knows what the final calculation will be.

Well it’s not that bad isn’t it ? It is going to be a simple sum, lets hardcode it and leave it alone.

Harcoding solution which is likely to change
Integer calculate1(Integer... numbers) {
    return numbers.sum()
}

void 'Composition: Just one calculation. No composition'() {
    given: 'two numbers as input'
        def first = 1
        def second = 2
    when: 'invoking the function'
        def result = calculate1(first, second)
    then: 'we should be getting the sum'
        result == 3
}

Now your boss comes again and gives you the whole formula: All numbers should be multiplied 2 times and then be divided by 10 and eventually yes they should be added up.

Ok, now you have to modify your code:

Modifying your logic
Double calculate2(Integer... numbers) {
    return numbers
        .collect { it * 2 }
        .collect { it / 10 }
        .sum()
}

void 'Composition: Calculation gets bigger. No composition'() {
    given: 'two numbers as input'
        def first = 10
        def second = 20
    when: 'invoking the function'
        def result = calculate2(first, second)
    then: 'the result should be the expected'
        result == 6
}

You may be thinking the code is still legibible and there is nothing wrong to keep it that way. Well I disagree. First of all you are looping the collection twice, that could be a lot of numbers, be carefull with that. And the second …​ will see that later ;)

I’m going to compose first two functions to be applied only once per item before adding up all numbers.

Composing
Double calculate3(Integer... numbers) {
    def twoTimes = { it * 2 } (1)
    def divideByTen = { it / 10 } (2)
    def composedFn = twoTimes >> divideByTen (3)

    return numbers
        .collect(composedFn) (4)
        .sum()
}

void 'Composition: Calculation gets bigger. Composing (I)'() {
    given: 'two numbers as input'
        def first = 10
        def second = 20
    when: 'invoking the function'
        def result = calculate3(first, second)
    then: 'the result should be the expected'
        result == 6
}
1 Declaring first part of the calculation
2 Declaring second part of the calculation
3 Combining both of them. Execution will be from left to right. First multiplication, then division
4 Using the combined function per each item

Composition could be done from left to right or the other way around, it depends on the developer’s decision. But this has to change a little bit more. We still have our functions

Composing
(1)
Double calculate4(Integer... numbers) {
    def operation =
        Calculations.divideByTen <<
        Calculations.twoTimes

    return numbers.collect(operation).sum()
}

(2)
Double applyFunctionAndSum(Closure<Number> fn, Integer... numbers) {
    return numbers.collect(fn).sum()
}

void 'Composition: Calculation gets bigger. Composing (II)'() {
    given: 'two numbers as input'
        def first = 10
        def second = 20
    when: 'invoking the function'
        def result1 = calculate4(first, second) (3)
        def result2 =
            applyFunctionAndSum(Calculations.twoTimes, first, second) (4)
    then: 'the result should be the expected'
        result1 == 6
        result2 == 60
}
1 I’ve moved functions that I will probably reuse to static methods. That way I can combine them without harcode them in my methods
2 In this method I describe the problem I’ve been dealing with. Applying a function to a list of numbers that eventually are going to be added up.
3 I’m using the composed function here
4 At this point I’m able to reuse the basic functionality to apply any single or combined function to it.

2.4. Currying

2.4.1. What is currying ?

The term takes its name from the american mathematician Haskell Curry. A good formal definition could be:

Currying is the technique of transforming a function that takes multiple arguments in such a way that it can be called as a chain of functions each with a single argument.

— Wikipedia

Currying is a special case of partial application which is:

In computer science, partial application (or partial function application) refers to the process of fixing a number of arguments to a function, producing another function of smaller arity…​

— Wikipedia

Why are both definitions important ? Well, although I’ve just showed you the formal definition of both currying and partial application in Groovy we tend to use the term currying most of the time meaning partial applications. From now on I will using the formal definitions mentioned above.

2.4.2. Using curry, ncurry, rcurry

There are three specialized methods for the Closure type in order to produce partial applications of your closures.

The first one is curry. This method takes a var-arg parameter in order to set any number of available closure parameters and return the partial application of it.

curry(…​)
void 'curry(...): partial application'() {
    given: 'a function taking a certain number of args'
        def fn1 = { a, b, c -> a + b + c } (1)
    when: 'producting another functions'
        def fn2 = fn1.curry(1) (2)
        def fn3 = fn1.curry(1, 2, 3) (3)
    then: 'different applications'
        fn2(4, 5) == 10
        fn3() == 6
}
1 A function having 3 parameters
2 We set the first parameter of the source function producing a new function with two parameters
3 This time we may want to set all parameters to pospone the execution of the function

Using curry(…​) you can pass at most the same number of arguments of the source closure, otherwise you will get an IllegalAgumentException. The parameters are set from left to right.

In case you wanted to produce partial applications of a given function applying fixed values from right to left, then you should be using rcurry(…​) method.

rcurry(…​)
void 'rcurry(...): partial application'() {
    given: 'a source function'
        def fn1 = { String name, Integer age, String city ->
            return "$name is $age and is from $city"
        }
    when: 'producing new funtions'
        def fn2 = fn1.rcurry('Madrid')
        def fn3 = fn1.rcurry(22, 'Barcelona')
    then: 'we could use them in several different ways'
        fn2('John', 37) == 'John is 37 and is from Madrid'
        fn3('Ronnie') == 'Ronnie is 22 and is from Barcelona'
}

rcurry may seem a little bit awkward because notice how parameters are passed to rcurry. One may expect to keep inverse order from right to left, I mean…​ if we had this function:

rcurry(…​) explanation
def myFunction = { String a, Integer b, Double c -> /*...*/ }

If we wanted to set two fixed parameters I may expect that rcurry should be applied like this:

rcurry(…​) wrong use
// WRONG
def myFunction2 = myFunction1.rcurry(22.2, 3)

But instead rcurry expects to kee the same order:

rcurry(…​) correct
// CORRECT
def myFunction2 = myFunction1.rcurry(3, 22.2)

Last but not least. If you would like to produce a partial application of a given closure for any parameter at any position you can use ncurry.

ncurry(…​)
void 'ncurry(...): partial application'() {
    given: 'a source function'
        def fn1 = { String name, Integer age, String city ->
            return "$name is $age and is from $city"
        }
    when: 'producing a new function'
        def fn2 = fn1.ncurry(1,22) (1)
    then: 'we should get the expected result'
        fn2('John', 'Madrid') == 'John is 22 and is from Madrid'
}
1 Here we want to set only the second parameter from the left hand side.

When using ncurry you just place the cursor at a given point and start setting fixed parameters from left to right.

2.4.3. Combining closures

The same way we wanted to compose functions to transform values, we may want to do the same thing with filtering.

This time we will change perspective. Instead of applying composed filters I think it would be more interesting how to aggregate filters in order to apply them, for example, to a collection.

Think about an SQL operation, we wouln’t want the database engine to apply each filter for every row and aggregate the result from the previous execution, Would we? That would be crazy ? So if the database engine doesn’t do it, neither do I.

Our starting point is the less efective implementation where we’re repeating our loop per each filter

Filtering several times
void 'Composing for filtering: no composition'() {
    given: 'a huge list of numbers'
        def numbers = (1..1000)
    when: 'applying several filters...wrong'
        def result =
            numbers
                .findAll { it % 2 == 0 }
                .findAll { it > 100 }
                .sum()
    then: 'we should get the expected result'
        result == 247950
}

I can’t combine both filters as I did with transformation in the previous chapter. Because the result of applying a filter is a boolean value. Than boolean value will be passed as the argument of the next function in line, and it will fail because all our filters are expecting a number.

The strategy requires to apply a partial application of the function. Let’s show how to do it with normal Xcurry methods.

Combining filters using rcurry
Closure<Boolean> combineFiltersVerbose(final Closure<Boolean>... filters) {
    Closure<Boolean> allFiltersCombined = { Integer number, Closure<Boolean>... allFilters -> (1)
        allFilters*.call(number).every()
    }

    return allFiltersCombined.rcurry(filters) (2)
}

void 'Combining filters with rcurry'() {
    given: 'a huge list of numbers'
        def numbers = (1..1000)
    and: 'composing filtering'
        def even = { it % 2 == 0 }
        def greaterThanHundred = { it > 100 }
        def byCriteria = combineFiltersVerbose(even, greaterThanHundred) (3)
    when: 'applying several filters'
        def result = numbers.findAll(byCriteria).sum() (4)
    then: 'we should get the expected result'
        result == 247950
}
1 First we create a closure with two parameters. We need to add some filters. All filters should be executed for every number
2 We need to use rcurry to set filters, because var-args arguments can only be the last parameter of a function
3 Passing all filter we want to apply in order
4 Filtering numbers

Now we will be applying all filters for every single item, just once. We made our filtering process more efficient. Well done !!

It’s true that sometimes it’s a little bit verbose to use Xcurry(…​) methods but it’s also true that using that technique functions are more reusable.

Here there is another technique which consist of making functions return other functions. Eventually is what Xcurry(…​) methods will do for you underneath, but sometimes may look clearer to the reader what the partial application tries to do.

Combining filters making a closure to return another closure
Closure<Boolean> combineFilters(final Closure<Boolean>... filters) {
    return { Integer number -> (1)
        filters*.call(number).every()
    }
}

void 'Combining filters with closure combination'() {
    given: 'a huge list of numbers'
        def numbers = (1..1000)
    and: 'composing filtering'
        def even = { it % 2 == 0 }
        def greaterThanHundred = { it > 100 }
        def byCriteria = combineFilters(even, greaterThanHundred) (2)
    when: 'applying several filters'
        def result = numbers.findAll(byCriteria).sum() (3)
    then: 'we should get the expected result'
        result == 247950
}
1 In just one call we are using the behavior of closures to set the filters we will be using without having to use any Xcurry function
2 Passing all filter we want to apply in order
3 Filtering numbers

Why can I do step number 1 ? Because the closure’s filter value is set when the closure is declared with the references at that time. Afterwards those values won’t change. Anyway I made sure that couln’t happen because I declare filters as a final parameter.

2.5. Delegation strategy

Closures can use different strategies to resolve some property references and methods. Before talking about strategies, and how to change the order of resolution, there are some important concepts we must know up front.

Definition of every concept is taken from the Closure javadoc at http://groovy.codehaus.org/api/groovy/lang/Closure.html
  • delegate : the delegate Object to which method calls will go which is typically the outer class when the closure is constructed

  • owner : the owner Object to which method calls will go which is typically the outer class when the closure is constructed

I want you to notice how many times the word typically is used. Here it would mean everything will happen this way if the default resolution strategy is used

There are 4 different strategies:

  • OWNER_FIRST : (default) With this resolveStrategy set the closure will attempt to resolve property references and methods to the owner first, then the delegate.

  • OWNER_ONLY : With this resolveStrategy set the closure will resolve property references and methods to the owner only and not call the delegate at all.

  • DELEGATE_FIRST : With this resolveStrategy set the closure will attempt to resolve property references and methods to the delegate first then the owner.

  • DELEGATE_ONLY : With this resolveStrategy set the closure will resolve property references and methods to the delegate only and entirely bypass the owner

Strategies definition have been taken from the Closure javadoc at http://groovy.codehaus.org/api/groovy/lang/Closure.html

The basic idea here is that we can change the order of the resolution of property references and methods. But before getting into detail of every one of them, I would like to know what is the normal resolution behavior of a Closure. In order to do that lets see this example:

Lexical scope
void 'default closure resolution'() {
    given: 'an instance of ClosureBehavior'
        def instance = new ClosureBehavior()
    expect: 'result to be two'
        instance.sum() == 6
}
Lexical scope
class ClosureBehavior {

    (3)
    def a = 1
    def b = 0
    def c = 0

    def sum() {
        (2)
        def b = 2

        Closure<Integer> cl = {
            (1)
            c = 3
            a + b + c
        }

        return cl()
    }

}

It seems that the closure follows lexical scope:

1 First tries to resolve in the closure scope
2 then goes up, to the local scope
3 and finally goes up again until reaches the class instance scope

But wait. I said default strategy was OWNER_FIRST then…​ why some of the variables are resolved by lexical scope ? Well I came up with the following example to help me to understand how the variables are resolved. As you may notice local variables always win vs strategies. Only global and delegate scope can be influenced by changing the resolution strategy.

Table 1. Resolution

Strategy

1st

2nd

3th

4th

OWNER_FIRST

local 2 closure

local

global

delegate

OWNER_ONLY

local 2 closure

local

global

none

DELEGATE_FIRST

local 2 closure

local

delegate

global

DELEGATE_ONLY

local 2 closure

local

delegate

none

With this table as a cheatsheet I’m going to do some examples of all strategies listed before.

2.5.1. OWNER FIRST

(TODO)

2.5.2. OWNER_ONLY

(TODO)

2.5.3. DELEGATE FIRST

(TODO)

2.5.4. DELEGATE_OWNER

(TODO)

2.6. Memoization

Although memoization is normally used for recursive calculations…​ don’t worry, this chapter doesn’t start with "yet another Fibonacci example".

We’ll get there, but I think is easier to think about memoization as a form of caching. A very simple one but caching nevertheless.

Imagine a very simple scenario. I would like a very simple cache to save n calls to…​database/network/…​etc and it’s so simple I would waste my time to use any fancy cache system.

In this first example, I’m simulating a way of getting users from a UserService class with a method findUserById returning users having the id passed as parameter.

Because I know memory is far more than the memory need to store all users in the given process, and because every call to that method really consumes a lot of time, I’ve decided to memoize it.

Memoized method
@groovy.transform.Memoized
   def findUserDataById(Integer userId) {
        println "Getting user [$userId] data"

        return [id: userId, name: "john doe $userId", timestamp: System.currentTimeMillis()]
   }

In order to cache the method invocation I annotated the method with the annotation groovy.transform.Memoize which creates a new cache at instance level.

Memoized method
void 'Using memoize for a given method'() {
    given: 'a invocation to get a user'
        def result = findUserDataById(1)
    and: 'waiting to check timestamp later'
        Thread.sleep(500)
    when: 'asking again for the same user'
        result = findUserDataById(1)
    then: 'if cache is expected timestamp should match'
        result.timestamp == old(result.timestamp)
}

This was an easy way of turning an existing method to a method with an "extra" cache. But what if we wanted to use a closure with the same feature.

Imagine we want to create a MD5 signature of every of a given list. It’s clear same word will become the same hash, so why bothering doing the calculation if we already know the outcome ?

Memoized closure
void 'Using a memoized closure'() {
     given: 'a list of words'
         def words = [\
             'car','peter','maggie',
             'ronnie','book','peter',
             'road','car','ronnie'
         ]
     and: 'building the memoized closure'
         def md5fromWord = { String word ->
             println "Word: $word" (1)
             java.security.MessageDigest
                 .getInstance("MD5")
                 .digest(word.getBytes("UTF-8"))
                 .encodeHex()
                 .toString()
         }.memoize() (2)
     when: 'collecting their md5 hashes'
         def md5Hashes = words.collect(md5fromWord) (3)
     then: 'checking figures'
         md5Hashes.size() == 9
         md5Hashes.unique().size() == 6
     // Word: car
     // Word: peter
     // Word: maggie
     // Word: ronnie
     // Word: book
     // Word: road
}
1 I will be printing every word to notice that, at some point, some of the invocation will be omitted.
2 In order to create a cache-included-closure we need to call memoized() method from Closure class and most important, use the closure returned by that method.
3 Then we can use that closure in a more efficient way :)

2.7. Trampoline

When writing recursive code, sometimes we can overflow the size of the stack and get and Stackoverflow exception. To prevent that situation, Groovy gives us two solutions:

  • Closure’s trampoline() method

  • @TailRecursion AST transformation

A good example is to try to add up a list of numbers recursively.

Recursion with trampoline()
void 'Trampoline: Adding up numbers recursively'() {
    given: 'a closure prepared to call itself recursively'
        def sumRecursively (1)
        sumRecursively = { List<Integer> numbers, aggregator = 0 ->
            if (!numbers) {
                return aggregator
            } else {
                sumRecursively.trampoline( (2)
                        numbers.tail(),
                        aggregator + numbers.head())
            }
        }
    when: 'usisng the transformed version of closure'
        sumRecursively = sumRecursively.trampoline() (3)
        def result = sumRecursively(1..10000)
    then: 'we should get the result without the stackoverflow exception'
        result == 50005000
}
1 We need to declare sumRecursively and then attach its behabior to the actual variable
2 Within the function every time we make a recursive call we must call to the "trampoline" version of the function
3 Finally to init the whole process execute a "trampoline" version of the closure

It works ok but it seems a little bit complicated. Get a version with trampoline() then not forget to call trampoline with arguments…​mmmmm

@TailRecursive transformation helps you to avoid dealing with that kind of details. You just focus on the implementation and it handles how to make the function to a recursive one. This AST transformation is avaiable since version 2.3 of Groovy.

The only requirement here is to put the recursive call as the last expression in the method body (at the tail, that’s why it’s called tail recursion optimization).

Recursion with @TailRecursive
@groovy.transform.TailRecursive
Integer recursiveSum(List<Integer> numbers, Integer aggregator = 0) {
    if (!numbers) {
        return aggregator
    } else {
        return recursiveSum(
            numbers.tail(),
            numbers.head() + aggregator
        )
    }
}

void 'TailRecursive: recursive sum'() {
    when: 'using the transformed method'
        def result = recursiveSum(1..10000)
    then: 'we should get the result without the stackoverflow exception'
        result == 50005000
}

2.8. Functional interface coercion

How do we used to pass filtering behavior to a collection if we didn’t have closures ? I’d started by declaring an interface declaring the intent of the filter:

Filter
package groovyfp.oop2fn

interface Filter<T> {
   Boolean accept(T element)
}

Then of course an implementation:

Filter implementation
package groovyfp.oop2fn

class EvenNumbersFilter implements Filter<Integer> {
    Boolean accept(Integer number) {
        return number % 2 == 0
    }
}

And that’s it. We can now use it:

How to use the functional interface
List<Integer> filterNumbersByFilter(List<Integer> numbers, Filter<Integer> filter) {
    List<Integer> resultList = new ArrayList()

    for (Integer number : numbers) {
        if (filter.accept(number)) {
            resultList.add(number)
        }
    }

    return resultList
}
How to use the functional interface
void 'Functional Interface: the old fashioned way'() {
    given: 'a list of numbers'
        def numbers = (0..10)
    when: 'filtering using the class wrapping the filtering behavior'
        def evenNumbers = filterNumbersByFilter(numbers, new EvenNumbersFilter())
    then: 'We should get the expected result'
        evenNumbers == [0, 2, 4, 6, 8, 10]
}

And now, how can we do the same in Groovy ? Well, in case we wanted to reuse the method receiving the Filter instance we can use closures coercion:

Closure coercion
void 'Functional Interface: closures coercion'() {
    given: 'a list of numbers'
        def numbers = (0..10)
    when: 'filtering using the class wrapping the filtering behavior'
        def filter = { it % 2 == 0 } as Filter (1)
        def evenNumbers = filterNumbersByFilter(numbers, filter) (2)
    then: 'We should get the expected result'
        evenNumbers == [0, 2, 4, 6, 8, 10]
}
1 Creation of an instance that implements the functional interface. The body of the closure is supposed to be the implementation of the only method that the interface had.
2 Then you can use it whenever you used to pass an instance of that object

3. Internal Vs External iteration

Most of the time we need to iterate through a list, we end doing the same. We tend to specify every detail, we code every step of the way. But is there any other way ? Well there is…​it’s call internal iteration.

The point here is that We should be taking care on the logic of filtering and transformation and not how to loop through the collection, Don’t you thing ?

There are some reasons I would recommend you to start using internal iteration:

  • Is more concise and clear

  • Reusability

  • Composition

  • Internal optimizations

3.1. More concise

Let’s say we have a list of mercenaries in lower case and we want to get their names in upper case. Well no problem…​That is what is should look like in old-fashioned Java code:

External Iteration: Java style
void 'External iteration. Java like code'() {
    given: 'A collection we want to iterate'
        def expendables = ['Stallone', 'Staham', 'Couture']
    when: 'Collecting the upper case version of the names'
        def expendablesUpperCase = []
        for(String name: expendables) {
            expendablesUpperCase << name.toUpperCase()
        }
    then: 'All names should be in upper case'
      expendablesUpperCase == ['STALLONE', 'STAHAM', 'COUTURE']
}
  • We have to remember to create the collection to store the transformed names.

  • Then we should know how the iteration is done

  • Finally to add explicitly every transformed name into the new collection.

Maybe Groovy is more concise and less verbose…​hell yeah but you can do it wrong either.

External Iteration: Groovy style
void 'External iteration. Groovy style code'() {
    given: 'A collection we want to iterate'
        def expendables = ['Stallone', 'Staham', 'Couture']
    when: 'Collecting the upper case version of the names'
        def expendablesUpperCase = []
        expendables.each { name ->
            expendablesUpperCase << name.toUpperCase()
        }
    then: 'All names should be in upper case'
      expendablesUpperCase == ['STALLONE', 'STAHAM', 'COUTURE']
}

"That’s not what I signed for!!!" you may think. Don’t worry Groovy has a lot more to offer. Collections in Groovy have many useful method to loop through them filtering and collecting transformed values without having to specify how a collection should be traversed.

Internal Iteration: Groovy
void 'Internal iteration (I)'() {
    given: 'A collection we want to iterate'
        def expendables = ['Stallone', 'Staham', 'Couture']
        def upperCaseVersion = { String word -> word.toUpperCase() }
    when: 'Collecting the upper case version of the names'
        def upperCaseExpendables = expendables.collect(upperCaseVersion)
    then: 'All names should be in upper case'
      upperCaseExpendables == ['STALLONE', 'STAHAM', 'COUTURE']
}

This example shows how you can loop through a collection in Groovy in a declarative way. You can almost read "I want to collect the upper-case-version of the expendable collection" can’t you ?

Of course you can embed the closure expression as a parameter instead of declaring the expression and then passing it to the collect method

Internal Iteration: Groovy
void 'Internal iteration (II)'() {
    given: 'A collection we want to iterate'
        def expendables = ['Stallone', 'Staham', 'Couture']
    when: 'Collecting the upper case version of the names'
        def upperCaseVersion = expendables.collect { it.toUpperCase() }
    then: 'All names should be in upper case'
      upperCaseVersion == ['STALLONE', 'STAHAM', 'COUTURE']
}

But later on you’ll see that sometimes is better not to use the Closure expression directly if you want to keep your code reusable.

3.2. Reusability

Imagine we had a method looping through a collection to sum all numbers less than 20.

Internal Iteration: Groovy
void 'external iteration: adding up all numbers from a given collection'() {
    given: 'a collection of numbers'
        def numbers = (0..1000)
        def sum = 0
    when: 'summing all of them'
        numbers.each { nextnumber ->
            sum += nextnumber
        }
    then: 'the expected result should be the expected'
        sum == 500500
}

Now we want to get all numbers from 20 to 100

Internal Iteration: Groovy
void 'External iteration: Adding numbers from 20 to 100 from a given collection'() {
    given: 'a collection of numbers'
        def numbers = (0..1000)
        def sum = 0
    when: 'adding up all of them'
        numbers.each { nextnumber ->
            if (nextnumber > 20 && nextnumber < 100) {
                sum += nextnumber
            }
        }
    then: 'the expected result should be the expected'
        sum == 4740
}

And now…​you know what ? forget it :P

There should be a better way of refactoring this behavior. There are two main actions when trying to solve these type of problems:

  • Filtering data

  • Transforming data

And when talking about Groovy and collections this means to use find or findAll when trying to filtering data and collect for transforming data.

Back to the prolem, while the transformation applied to the data is the same the filtering applied is different. Lets see how our reusable method should look like:

Internal Iteration: Filter + Transformation
Integer sum(
    final Collection<Integer> source, (1)
    final Closure<Boolean> filter = { it }) { (2)

    return source.findAll(filter).sum() (3)
}
1 First we pass the collection we want to transform. We say transform deliberately, we don’t want to mutate the collection but to create a new one for applying a given action. This case to sum all numbers of that new collection
2 We want to get certain numbers to add them up. By default if no filter given then apply to all ({ it }).
3 We’re using Groovy’s collection behavior to apply the given filter to get the new collection and then sum all numbers in that collection.

And how to use it for different filters:

Internal Iteration: Reuse of functions
void 'Internal iteration: Adding up with reusability'() {
    given: 'A collection of numbers'
        def numbers = (0..1000)
    when: 'adding up'
        def all = sum(numbers)
        def from20To100 = sum(numbers) {
            it > 20 && it < 100
        }
    then: 'Results should be the expected'
        all == 500500
        from20To100 == 4740
}

That’s great but the previous example shows us a way of reusing behavior through the use of methods. But Does it mean it will be forcing us to create a method every time we would like to reuse a certain behavior ? That would lead us to create a lot of methods don’t you think ?

Functional programming teach us that behavior is not limited to methods of an object. When talking about behavior we will be talking of functions in a more general way.

Functions are more powertful in the way that they can be modified, passed as a parameter to other functions, and still can be used as the methods we normally use. In Groovy such type of functions are called closures.

Although we will be talking about closures deeper in its own chapter lets say for now that they’re extremely useful to reuse behavior.

What if I want to use the same method with the same type of filter several times in the same method. That would be a lot of boiler plate code. A lot of code to maintain and repeat. Sounds too dirty…​ and looks worst :P

Internal Iteration: Reusability limited to methods ?
void 'Internal iteration: Reusability limited ? (I)'() {
    given: 'A collection of numbers'
        def numbers1 = [100, 20, 2, 54, 33, 14]
        def numbers2 = [100, 20, 2, 54, 33, 14]
        def numbers3 = [100, 24, 6, 48, 22, 40]
    when: 'adding up all numbers of first collection'
        def numbers1Sum = sum(numbers1)
    and: 'adding up numbers > 20 and < 100 for the remaining collections'
        def numbers2Sum = sum(numbers2) {
            it > 20 && it < 100
        }
        def numbers3Sum = sum(numbers3) {
            it > 20 && it < 100
        }
    then: 'Results should be the expected'
        numbers1Sum == 223
        numbers2Sum == 87
        numbers3Sum == 134
}

What can I do ? Well let’s say that Groovy methods could be transformed into closures…​ How ? As I said earlier functions / closures can be assigned and be passed as parameters.

Internal Iteration: Reusability limited to methods ?
void 'Internal iteration: Reusability limited ? (II)'() {
    given: 'A collection of numbers'
        def numbers1 = [100, 20, 2, 54, 33, 14]
        def numbers2 = [100, 20, 2, 54, 33, 14]
        def numbers3 = [100, 24, 6, 48, 22, 40]
    and: 'A fixed type of filter'
        def greaterThan20LessThan100 = { it > 20 && it < 100} (1)
    when: 'adding up all numbers of first collection'
        def numbers1Sum = sum(numbers1)
    and: 'adding up numbers > 20 and < 100 for the remaining collections'
        def numbers2Sum = sum(numbers2, greaterThan20LessThan100) (2)
        def numbers3Sum = sum(numbers3, greaterThan20LessThan100)
    then: 'Results should be the expected'
        numbers1Sum == 223
        numbers2Sum == 87
        numbers3Sum == 134
}
1 We assign the closure representing the filter to a given variable
2 Then we pass the closure as parameter to filter numbers

And also I said methods in Groovy can be transformed to closures:

Internal Iteration: Reusability limited to methods ?
void 'Internal iteration: Reusability limited ?'() {
    given: 'A collection of numbers'
        def numbers1 = [100, 20, 2, 54, 33, 14]
        def numbers2 = [100, 20, 2, 54, 33, 14]
        def numbers3 = [100, 24, 6, 48, 22, 40]
    and: 'A fixed type of behavior'
        def customSum = this.&sum.rcurry { it > 20 && it < 100} (1)
    when: 'adding up all numbers of first collection'
        def numbers1Sum = sum(numbers1)
    and: 'adding up numbers > 20 and < 100 for the remaining collections'
        def numbers2Sum = customSum(numbers2) (2)
        def numbers3Sum = customSum(numbers3)
    then: 'Results should be the expected'
        numbers1Sum == 223
        numbers2Sum == 87
        numbers3Sum == 134
}
1 We are creating a new function with a fixed type of filter
2 We have created a new function that sums all numbers greater than 20 and less than 200 for the collection passed as parameter
If the expression this.&sum.rcurry sounds like chinese to you just take that this expression is only saying: I want to get a new function with the first parameter from the right with the following value { it > 20 && it < 100}. Anyway I recommend you to review the chaper dedicated to closures.

3.3. Composition

Today’s specifications may change. Lets say I want to trim all strings coming from a given collection. But then my boss comes and tells me he wants all words uppercase.

Looping more than neccessary
void 'Specifications change. Looping Twice'() {
    given: 'a list of words'
        def words = [' animal', ' person', 'something else ']
    and: 'a couple of transformations'
        def trim = { it.trim() }
        def toUpperCase = { it.toUpperCase() }
    when: 'applying transformations one after another'
        def result =
            words
                .collect(trim) (1)
                .collect(toUpperCase) (2)
    then: 'we should get a cleaned list of words'
        result == ['ANIMAL', 'PERSON', 'SOMETHING ELSE']
}

The problem is that we’re looping the word list twice

1 first to trim all words and then
2 we’re looping again to convert every word to uppercase.

With composing both behaviors we can apply both at once for every word. We will be saving a loop for every new transformation. That’s worth knowing right ?

Composing behavior
void 'Specifications change. Composition'() {
    given: 'a list of words'
        def words = [' animal', ' person', 'something else ']
    and: 'a couple of transformations'
        def trim = { it.trim() }
        def toUpperCase = { it.toUpperCase() }
        def trimAndUpperCase = toUpperCase << trim (1)
    when: 'applying transformations one after another'
        def result = words.collect(trimAndUpperCase)
    then: 'we should get a cleaned list of words'
        result == ['ANIMAL', 'PERSON', 'SOMETHING ELSE']
}
1 This is a special notation for composing closures. The composition has to be read from right to left. The first behavior to be taken is the first on the right.

4. Streams

So far, we’ve seen that in Groovy, filtering elements and applying transformation over that collection is as easy as a pie right ? But we didn’t realize we could be more efficient in the way we do those tasks.

4.1. Mind the lazyness

Imagine we want to filter even numbers from a given collection and then multiply them 10 times.

Working more than you should
void 'Multiply even numbers 10 times'() {
    given: 'A collection of numbers'
        def numbers = (0..10)
    when: 'Filtering and transforming numbers'
        def result =
            numbers
                .findAll { it % 2 == 0} (1)
                .collect { it * 10 } (2)
                .collect { it + 1 } (3)
    then: 'We should get the expected result'
        result == [1, 21, 41, 61, 81, 101]
}
1 We loop through the entire collection to get all required values
2 Then we loop through the filtered values to apply some transformation
3 Then we loop one more time to apply another transformation

It’s clear we should be able to loop only once the collection while applying the transformation only to the required values. In this particular example is not critical, but imagine we were looping a collection with thousands of elements, going through that collection more than once wouldn’t be very nice so to speak.

Let see what says the wikipedia about streams in this context:

…​A stream is a lazily evaluated or delayed sequence of data elements. A stream can be used similarly to a list, but later elements are only calculated when needed. Streams can therefore represent infinite sequences and series.

— Wikipedia

So how can we modify previous example to make it process the required values on the fly, as soon as the process detectes they are suitable to be part of the result ?

If we only wanted to combine transformations we could have done something like this:

Combine transformations
void 'Multiply even numbers 10 times'() {
    given: 'A collection of numbers'
        def numbers = (0..10)
        def multiplyTenTimes = { x -> x * 10}
        def byEvenNumber = { x -> x % 2 == 0 }
        def plusOne = { x -> x + 1 }
    when: 'Filtering and transforming numbers'
        def result =
            numbers
                .findAll(byEvenNumber) (1)
                .collect(multiplyTenTimes >> plusOne) (2)
    then: 'We should get the expected result'
        result == [1, 21, 41, 61, 81, 101]
}

Ok, but now I would like one step futher and apply filters and transformations per each item in the list.

Although later on we’ll be seeing there’re at least a couple libraries that can do it for you in a easy way. But for now we have to make do with Groovy alone.

Two tasks at once
void 'Multiply even numbers 10 times lazily'() {
    given: 'A collection of numbers'
        def emptyList = []
        def numbers = (0..10)
        def multiplyTenTimes = { x -> x * 10}
        def byEvenNumber = { x -> x % 2 == 0 }
        def plusOne = { x -> x + 1 }
    when: 'Filtering and transforming numbers'
        def result =
            numbers.inject(emptyList) { acc, val ->
                if (val % 2 == 0) {
                    acc << plusOne(multiplyTenTimes(val))
                }
                acc
            }
    then: 'We should get the expected result'
        result == [1, 21, 41, 61, 81, 101]
}

We have use the collection inject method. This method receives two arguments:

  • Initial value of the aggregated data

  • A closure receiving two parameters: the agregated data, and the next value of the source collection

Now the process declares which element the transformation has to be applied to and then add it to the result. We don’t have to loop the collection twice we are doing both filtering and transformation all at once.

Now we reached the goal, the process is more efficient but the problem is that I don’t like the code, it’s not reusable. So it’s time to change it.

I’ve based my implementation in the JDK8 Stream API. Of course this is a very basic implementation, but it shows how lazy evaluation could be implemented.

Simple Stream
package groovyfp.streams

final class Stream {

    final Collection<?> col
    Closure<Boolean> filter
    Closure<?> transformer
    Integer howMany

    Stream(Collection<?> col) {
       this.col = col
    }

    static Stream from(Collection<?> source) {
        return new Stream(source)
    }

    Stream filter(Closure<Boolean> filter) {
        this.filter = filter
        this
    }

    Stream map(Closure<?> transformer) {
        this.transformer = transformer
        this
    }

    Stream take(Integer howMany) {
        this.howMany = howMany
        this
    }

    Collection<?> collect() {
        def result = []

        col.takeWhile { val ->
            if (filter(val)) {
                result << transformer(val)
            }
            howMany ? (result.size() < howMany) : true
        }

        return result
    }

}

Most of the code initializes both the filter and transformer of the collection. But the interesting part is in the collect() method:

1 The filter is applied to any element. If the element is suitable to be added to the result then…​
2 The transformation is applied to the element, and finally the element is added to the result.

Now if we change our test code, it should look like the following:

Functional lazy
void 'Multiply even numbers 10 times lazily (nicer way)'() {
    given: 'A collection of numbers'
        def numbers = (0..10)
        def multiplyTenTimes = { x -> x * 10}
        def byEvenNumber = { x -> x % 2 == 0 }
        def plusOne = { x -> x + 1 }
    when: 'Filtering and transforming numbers'
        def result =
            Stream
                .from(numbers)
                .filter(byEvenNumber)
                .map(multiplyTenTimes >> plusOne)
                .take(2)
                .collect()
    then: 'We should get the expected result'
        result == [1, 21]
}

Notice that even though I could be possibly looping through a huge number of items, I’m only processing the minimum possible amount.

Although there is a method in Groovy called take(Integer) which can be used to get a certain number of items from a given collection/iterable/iterator as far as I know it can’t be used for an infinite collection.

4.2. stream-groovy

It’s great to know to understand how to build lazy estructures, but it’s even better to use libraries already created to do that work for you.

Tim Yate’s stream-groovy is one of the libraries I will be reviewing in this chapter. What’s this library for ?

Groovy-stream is a library for Groovy that lets you create lazy Iterators (or streams) based on Iterators, Collections, Maps, Iterables or other Streams.

— stream-groovy site

Earlier I built a simple class that helped me to loop through a collection and filter data while applying a single transformer. In other words I was able to create a stream for a single data set and apply a single filter and transformer to the required values.

It was nice for that case but with many limitations.

  • What if I want to combine more than one stream ?

  • What if I want to combine more than one filter ?

  • What if I want to combine more than one transfomer ?

Instead of reinventing the wheel lets see how stream-groovy can help you to do that.

4.2.1. First steps

stream-groovy getting started
void 'Getting double values from even numbers of a given collection'() {
    when: 'Processing the stream'
        def result =
            Stream.
                from(0..5). (1)
                filter { it % 2 == 0 }. (2)
                map { it * 10 }. (3)
                collect() (4)
    then: 'We should get the expected results'
        result == [0, 20, 40]
}

This example looks pretty similar to example in the previus chapter right ? Busted!!! ;)

I’d like to point out some important parts:

1 We want to loop through a stream. A stream could be created using the different overloaded versions of the from method.
2 Filtering the stream, and processing only the values matching this expression. You will chose what elements to process thanks to the filter method.
3 We’re applying a transformation. This time I want to get 10 times of every element in the stream. You will normally use map to express a transformation.
4 Eventually I would like to get the transformated data. Because the result of the transformation is an instance of Iterable I can use methods such as collect(), next(), find(), findAll()

4.3. Creating a Stream

As I mentioned in the previous chapter your can start creating a stream using the method Stream.from()

stream-groovy getting started
void 'Creating streams'() {
    when: 'building streams from collections and iterables'
        def stream1 = Stream.from({ x++ }).using(x: 1) (1)
        def stream2 = Stream.from([1, 2, 3]) (2)
        def stream3 = Stream.from(50..100) (3)
        def stream4 = Stream.from(x: 0..2, y: 4..2) (4)
    and: 'from an iterator instance'
        def x = 0
        def iterator = [hasNext: { true }, next: { x++ }] as Iterator
        def stream5 = Stream.from(iterator) (5)
    and: 'also from another stream'
        def stream6 = Stream.from(stream1) (6)
    then: 'values generated by the stream invocations'
        stream1.take(2).collect() == [1, 2]
        stream2.take(2).collect() == [1, 2]
        stream3.take(4).collect() == [50, 51, 52, 53]
        stream4.take(2).collect() == [[x:0, y:4], [x:0, y:3]]
    and: 'using until instead of take'
        stream5.until{ it > 3}.collect() == [0, 1, 2, 3]
        stream6.until{ it > 6}.collect() == [3, 4, 5, 6]
}

In general you can create a stream from an iterable instance such as collections, or any class implementing java.util.Iterable, or creating a generator with the following expression:

Beware of not limiting the number of elements you want to receive from a generator. You might be creating a infinite loop!!!

4.4. NBA time

This year I talked about functional programming at the Greach conference in Madrid and most of the examples were about NBA games.

One of the examples were about getting the maximum difference in an NBA game of all times. I started from an imperative style code, and then I was moving until getting a decent functional sample.

However I think I didn’t show how a lazy stream could beat the last example. Well it’s about time!!

Non lazy approach
void 'Maximum difference in an NBA game: non lazy'() {
    when: 'Csv iterable'
        def result = csv
                .findAll(byDateFunction)
                .collect(differenceFunction)
                .max()
    then: 'The result should be the expected'
        result == 45
}

And the lazy counterpart:

Lazy approach
void 'Maximum difference in an NBA game: lazy'() {
    when: 'Csv iterable'
        def result =
            Stream
                .from(csv)
                .filter(byDateFunction)
                .map(differenceFunction)
                .max()
    then: 'The result should be the expected'
        result == 45
}

I’ve used the same functions for filtering data and calculating the difference in every game for both examples.

Filter
def getByDateFunction() {
    return { row ->
       row.date.endsWith('2013')
    }
}
Transformation
def getDifferenceFunction() {
    return { row ->
        [row.homePoints, row.visitorPoints]*.
            toInteger().
            sort().
            with {
                last() - first()
            }
    }
}

Altough this time I didn’t use the whole NBA data set, however results are clear, the non lazy approach took more than twice as long as the lazy code.

So next time you think about lazyness…​.well just keep this in mind…​ maybe is not that bad after all.

5. Immutability

(TODO)

6. OOP Revisited

Most of the time is hard to think in terms of functional programming because we are not used to do it. I was born as an OOP programmer, and it’s now when I’ve started digging into functional programming.

So I guess that a friendly way of travelling to the functional land would be to pass through some of the object-oriented places we’ve been working on for the past 20 years. Do you want to join me in this trip ? Lets go!

I’ve followed the list of oop patterns discussed in the book "Functional Programming Patterns" by Michael Bevilaqua-Linn.

Object oriented languages that doesn’t have functions as first citizens have to make do with classes and methods in order to be able to pass behavior to another classes or methods.

6.1. State

Closures have an important characteristic, which is they capture the "state" of the scope where they were created.

IMHO the wrong way of thinking about this topic is the following example, which mutates one of the references the closure is using.

State (Wrong)
void 'State: using state wrong (I)'() {
    given: 'an object used in a closure'
        def state = new State(discount:50) (1)
        def closure = { price ->
            price * (state.discount / 100) (2)
        }
    when: 'calculating the price discount'
        def result1 = closure(100)
    and: 'changing state value'
        state = new State(discount:20) (3)
        def result2 = closure(100)
    then: 'the second result is different'
        result1 != result2
}
1 We declare a given discount to apply to some prices.
2 The scope is so wide there is the risk someone could mutate the state reference value
3 The worst happened. We mutated state and the result of calling the closure with the same value changes. If you care about mutability, this is not good.

How can we pass state without mutating references used by our closure. I’ve changed the example a little bit:

State
void 'State: using state wrong (II)'() {
    given: 'an object used in a closure'
        def state = new State(discount:50) (1)
    and: 'reducing the closure avaiable scope when is created'
        def closure = { State st -> (2)
            return { price ->
                price * (st.discount / 100)
            }
        }
    when: 'calculating the price discount'
        def closureWithImmutableState  = closure(state)
        def result1 = closureWithImmutableState(100)
    and: 'changing state value'
        state = new State(discount:20) (3)
        def result2 = closureWithImmutableState(100)
    then: 'the second result is different'
        result1 == result2
}
1 We declare the state at a given point
2 We declare the closure, but notice that when the inner closure is created it only sees the state when it was created nothing more.
3 That’s way when the state variable mutates the execution of the closure remains the same

6.2. Command

Command pattern normally wraps a certain behavior, and that behavior is passed to another function or object to execute that behavior with the data found at the destination function or object.

Imagine I want to purchase online two tickets, and I can chose between paying the VIP tickets or the regular ones. Depending on my choice the payment process will charge me differently.

Object receiving command
package groovyfp.oop2fn

class PurchaseEntry {

    BigDecimal price

    BigDecimal applyPurchaseProcess(PurchaseProcess process) {
        return process.calculate(price)
    }

}

The purchase order has the normal price of the purchase, and depending on the process applied, the final amount could be changed.

Contract of the command
package groovyfp.oop2fn

interface PurchaseProcess {
    BigDecimal calculate(BigDecimal price)
}

All processes passed to the process entry, should comply to the PurchaseProcess interface. Remember we can create a closure and coerce it to become a functional interface.

Using command pattern
void 'Command: passing behavior to another class'() {
    given: 'a given purchase has a certain price'
        def purchaseEntry = new PurchaseEntry(price: 200) (1)
    when: 'two different purchase processes'
        def result = purchaseEntry.applyPurchaseProcess(process) (2)
    then: 'the price is the expected depending on the process'
        result == expectedPrice
    where: 'possible processes are'
        process                           | expectedPrice
        { price -> price }                | 200 (3)
        { price -> price += price * 0.3 } | 260 (4)
}
1 Initializing the entry with the initial price
2 Applying each of the processes to check different values
3 Declaring each process and the expected prices after applying those processes to the entry

6.3. Immutable objects instead of Builder

Six years ago I remember creating builder objects in Java not only because I was preserving immutability (I didn’t care about it at that time) but also because using a builder with a fluent API (using the chain pattern of course) was like using a DSL.

Nowadays with Groovy both of those "requirements" can be achieved by using the @Immutable transformation and the fact that you can use maps when building new instances of an object.

We want to build and immutable object, or an object as immutable as it could be. Our object carries information about a given video. Here is the Java-Style builder.

Video
package groovyfp.oop2fn

import groovy.transform.TupleConstructor

@TupleConstructor
class Video {
    String name
    String type
    long length

    void setName(String name) {}
    void setType(String type) {}
    void setLength(Long length) {}
}

In order to make Video object immutable (and not using @Immutable as we will see later on) I came with this idea of forcing to create all possible constructors to be able to initialize class fields using constructors and then overriding the setters.

I guess it would be easier if we could declare fields as private and Groovy would care about private but so far it doesn’t. So even if the field is private you can access to it.

Even in Java through the Reflection API you can access to the value of a private field.

Next is the builder itself. It has a fluent API so if you use an IDE you will be please about concatenating builder methods to initialize and build a new instance of Video class.

Video Builder
package groovyfp.oop2fn

class VideoBuilder {

    String name
    String type
    Long length

    static VideoBuilder builder() {
        return new VideoBuilder()
    }

    VideoBuilder name(String name) {
        this.name = name
        return this
    }

    VideoBuilder type(String type) {
        this.name = name
        return this
    }

    VideoBuilder length(Long length) {
        this.length = length
        return this
    }

    Video build() {
        return new Video(name, type, length)
    }

}

Finally both classes interact together in the following specification.

Using builder
void 'Immutability through Builder'() {
    given: 'an object built by a builder'
        def video =
            VideoBuilder
                .builder()
                .name('trip.avi')
                .type('mp4')
                .length(100000)
                .build()
    when: 'trying to mutate the object'
        video.name = 'anothervideo'
    then: 'the instance should not have been mutated'
        video.name == 'trip.avi'
}

This is a lot of code right ? Since Groovy 1.7 @Immutable annotation is avaiable. This annotation applies an AST transformation to make your classes almost immutable. To see the particulars of what @Immutable can do for you, I’d recommend you to check the GroovyDoc, it’s very detailed.

ImmutableVideo
package groovyfp.oop2fn

import groovy.transform.Immutable

@Immutable
class ImmutableVideo {
    String name
    String type
    long length
}
Using @Immutable
void 'Immutability through @Immutable'() {
    given: 'an immutable instance'
        def video = new ImmutableVideo(
            name: 'video.mp4',
            type: 'mp4',
            length: 12434
        )
    when: 'trying to mutate the object'
        video.name = 'somethingelse.avi'
    then: 'an exception will be thrown'
        thrown(Exception)
}

The main difference between the Builder instance and the use of the @Immutable annotation is that the use of the annotation will thrown an exception every time you try to access to any of the fields of the anotated class, while the instance built with the builder will just ignore your attempts to change the value of your fields.

Maybe there are more solutions to that problem, like a friend of mine says…​.pull-requests are welcome :-)

6.4. Replacing Iterator

Most of the ideas about this topic have been already discussed in Internal vs External Iteration.

The only idea I want to touch here is sequence comprehensions.

Why comprehensions are so appealling. Have you ever tried to loop through two collections at a time to get values combined ? I’m sure you have. How did it look like ? I bet it was pretty much like this:

Looping hell
void 'Looping two collections at the same time'() {
    given: 'two different collections'
        def collection1 = (10..12)
        def collection2 = (60..62)
    and: 'the collection combining the result'
        def combination = []
    when: 'combining both collections'
        collection1.each { outer ->
            collection2.each { inner ->
               combination << [outer, inner]
            }
        }
    then: 'values should be the expected'
        combination == [
            [10, 60],
            [10, 61],
            [10, 62],
            [11, 60],
            [11, 61],
            [11, 62],
            [12, 60],
            [12, 61],
            [12, 62]
        ]
}

Unfortunately Groovy doesn’t have comprehensions inbuilt in the language. But good news you have some options. You can use Tim Yates' stream-groovy library which have among others some comprehensions implementation.

stream-groovy comprehensions
void 'Groovy comprehensions using stream-groovy'() {
    given: 'two different collections'
        def collection1 = (10..12)
        def collection2 = (60..62)
    when: 'combining both collections using stream-groovy'
        def combination =
            Stream
                .from(x: collection1, y: collection2)
                .map { [x, y] }
                .collect()
    then: 'the results should be the expected'
        combination == [
            [10, 60],
            [10, 61],
            [10, 62],
            [11, 60],
            [11, 61],
            [11, 62],
            [12, 60],
            [12, 61],
            [12, 62]
        ]
}

6.5. Template pattern

The intent of the template pattern is to describe a process skeleton in an abstract class and let subclasses to implement the behavior of some parts of the process.

The example we’re using is an imaginary financial calculation. Imagine a bank that depending on its clients applies a different values for some parts of the calculations…​weird right ?

Apart from the details the process is always the same adding up the amount, the applied taxes and then possible extra costs.

First lets see how it would look like using a classical object oriented approach.

Abstract class
package groovyfp.oop2fn

abstract class AbstractFinancialProcess {

    abstract Double calculateTaxes(Double amount)
    abstract Double calculateExtras(Double amount)

    Double calculate(Double amount) {
        return amount +
            calculateTaxes(amount) +
            calculateExtras(amount)
    }

}

For good clients the bank doesn’t charge much:

Soft financial calculation
package groovyfp.oop2fn

class FinancialProcessSoft extends AbstractFinancialProcess {

    Double calculateTaxes(Double amount) {
        return amount * 0.01
    }

    Double calculateExtras(Double amount) {
        return amount * 0.2
    }

}

For bad clients the picture doesn’t look that well:

Hard financial calculation
package groovyfp.oop2fn

class FinancialProcessHard extends AbstractFinancialProcess {

    Double calculateTaxes(Double amount) {
        return amount * 0.10
    }

    Double calculateExtras(Double amount) {
        return amount * 0.5
    }

}

And then of course testing the process with these two implementations:

Template pattern object oriented approach
void 'Classical template method implementation'() {
    given: 'One concrete subclass implementation'
        def softCalculation = new FinancialProcessSoft()
    and: 'another different implementation based in the same parent'
        def hardCalculation = new FinancialProcessHard()
    expect: 'both results differ using the same process'
        softCalculation.calculate(100) !=
        hardCalculation.calculate(100)
}

So how to turn this pattern to a functional style of programming ?

Well the abstract class which represented the process could be translated to a function (I meant a closure):

Template now is a higher function
Closure<Double> calculate = {
        Closure<Double> calculateTaxes,
        Closure<Double> calculateExtras,
        Double amount ->

    return amount + calculateTaxes(amount) + calculateExtras(amount)
}

Then we can create functions to "fill" the implementation gaps of this process

Specific details
Closure<Double> calculateSoftTaxes = { Double amount ->
    return amount * 0.01
}

Closure<Double> calculateSoftExtras = { Double amount ->
    return amount * 0.2
}

Finally we use the functions to calculate the final amount:

Using functional template pattern
void 'Template pattern using functions'() {
    when: 'calculating using predefined functions'
        def result1 =
            calculate(
                calculateSoftTaxes,
                calculateSoftExtras,
                100
            )
    and: 'calculating using anonymous functions'
        def result2 =
            calculate(
                { amount -> amount * 0.2 },
                { amount -> amount * 0.10 },
                100
            )
    then: 'same process...different results...with less code'
        result1 != result2
}

Because we’re using functions we can be more flexible about how to compose and reuse different combinations of functions.

By the way, in many of the examples variables are typed. This is intentional because I want reader to know what the functions really return. Depending on the situation typing is really up to you
Building a reusable function on the fly
void 'Composing functions to reuse templates'() {
    when: 'building a preset calculation'
        Closure<Double> customCalculation = { Double amount ->
            calculate(
                calculateSoftTaxes,
                calculateSoftExtras,
                amount
            )
        }
    then: 'you can reuse it along your code'
        customCalculation(100) == 121.0
}

6.6. Strategy

The intent of this pattern is to declare a process that uses an algoritm that can be implemented in several ways

Lets say we are working in a video cassette company (an we’re in the 90’s :P). We belong to the quality department and we want to filter those videos not passing minimal standard validation. But the problem is that depending on the country the minimal validation changes.

Different strategies
List<ImmutableVideo> findAllFaultyVideo(List<ImmutableVideo> videoList, Closure<Boolean> validationStrategy) {
    return videoList
        .findAll(validationStrategy) (1)
        .asImmutable() (2)
}

Closure<Boolean> strategy1 = { ImmutableVideo video -> video.type == 'mp4' } (3)
Closure<Boolean> strategy2 = { ImmutableVideo video -> video.length < 700  } (4)
1 The validation strategy is applied to the collection filter
2 Because we want to use good functional practices we dont want anybody to alter the result list
3 The first strategy will detect as invalid mp4 videos
4 The second strategy will detect as invalid videos with size less than 700 bytes
Strategy test
void 'Changing the validation strategy'() {
    given:'A list of cars'
        List<ImmutableVideo> videoList = [
            [name: 'video1', type: 'avi', length: 1000],
            [name: 'video2', type: 'mp4', length: 1000],
            [name: 'video3', type: 'avi', length: 500] ,
            [name: 'video4', type: 'mp4', length: 1000],
            [name: 'video5', type: 'mp4', length: 50]
        ].asImmutable() as ImmutableVideo[]
    when: 'applying different strategies to the same list'
        def result1 = findAllFaultyVideo(videoList, strategy1)
        def result2 = findAllFaultyVideo(videoList, strategy2)
    then: 'you will have different result size'
        result1.size() == 3
        result2.size() == 2
}

6.7. Fighting Null Object

Null pointer exceptions are the plague of our era in computing programming. There are studies on how many millions are wasted because of this problem.

Here I’m going to show you a couple solutions to tackle this problem:

  • Groovy truth

  • Optional pattern

The problem of NullPointerException is not only the sad surprise of an exception during runtime but also the amount of lines of code you have to spend to make your code "safe". There is a lot of boilerplate code involved.

I will use a really simple example to try to show the problem and the possible solutions to it.

We have a method to get the number of letters of a given word. You can pass a String or unfortunately a null value.

Null
Integer countLetters(String name) {
    return name.length() (1)
}

void 'Fighting NPE: Groovy truth (I)'() {
    given: 'A word'
        def word = null
    when: 'Invoking the method'
        def result = countLetters(word) (2)
    then: 'A NPE will be thrown'
        thrown(NullPointerException)
}
1 The method calls to the lenght method of the value passed as parameter
2 When the value of the variable passed as parameter is null the method will throw a NPE trying to access a method from a null value.

Although using the Groovy safe operator (?) is not the one-for-all solution. It is a good starting point to avoid NPE problems.

Groovy safe operator
Integer countLettersGroovyTruth(String name) {
    return name?.length() (1)
}

void 'Fighting NPE: Groovy truth (II)'() {
    given: 'A word'
        def word = null
    when: 'Invoking the method'
        def result = countLettersGroovyTruth(word) (2)
    then: 'No exception will be thrown'
        notThrown(NullPointerException)
    and: 'The method to return null'
        result == null
}
1 We mark the reference as safe.
2 When trying to access some methods, or fields from that object, Groovy wil check whether the reference is null or not. In case it were null then the evaluation won’t go any further and the expression will return null.

The null value in Groovy is not the null of Java. It’s backed by NullObject.

Null is not what it seems
void 'Null is not null'() {
    expect: 'That null is not what it seems'
        null.getClass() == org.codehaus.groovy.runtime.NullObject
}

This object helps us to apply one of the principals of the Groovy truth. So whenever we had a null reference we can use it as a boolean value, which of course always will evaluate to false.

Groovy truth
void isNullThis(anything) {
    if (!anything) {
        println "Is null"
    } else {
        println anything.class.simpleName
    }
}
Null as boolean
void isNullThis(anything) {
    if (!anything) {
        println "Is null"
    } else {
        println anything.class.simpleName
    }
}

Ok, null is an instance of NullObject, so How this helps ? Well if you check out the list of methods NullObject has you will figure out some things. The most remarkable is that you don’t have to use safety when accessing collections.

Collections are safe
List<String> doSomething(List<String> words) {
    return words
        .findAll { it.startsWith('j') }
        .collect { it.toUpperCase() }
}

void 'Collections are safe'() {
    given: 'two different collections'
        def cities = null
        def names = ['john', 'jeronimo', 'james']
    when: 'filtering and transforming cities'
        def citiesResult = doSomething(cities)
    and: 'doing the same for names'
        def namesResult = doSomething(names)
    then: 'we should get at least an empty list'
        citiesResult == []
        namesResult == ['JOHN', 'JERONIMO', 'JAMES']
}

This is because all instances of a GroovyObject have some methods by default (methods declared in DefaultGroovyMethods class)

Unfortunately when dealing with plain pogos or primitive wrappers this functionality doesn’t help a lot. Imagine we were using the findAll or collect methods to avoid NPE…​ that would be insane don’t you think ? Or maybe not ?

Plain objects are not easy to deal with
void 'Groovy truth: insane ?'() {
    when: 'mapping values from a non safe reference'
        def result =
            source
                .collect { it }
                .join()
                .toUpperCase()
    then: 'the result should be the expected'
        result == expected
    where: 'possible values could be'
        source | expected
        null   | ""
        "john" | "JOHN"
}

In order not to end doing that kind of coding, Groovy has the elvis operator, which a way of providing a default value.

Elvis comes to the rescue
void 'Using elvis operator'() {
    when: 'preparing the item'
        def name = source ?: 'john doe' (1)
    then: 'all values should have more than one letter'
        name.toUpperCase() == expected (2)
    where: 'possible values are'
        source  | expected
        null    | "JOHN DOE"
        "peter" | "PETER"
}
1 In case the value is null use 'john doe' as value
2 You can call safely to toUpperCase method
Another elvis example
void 'Using elvis operator: another example'() {
    when: 'creating default reference'
        def video2Process = video ?: new ImmutableVideo(name:'unknown') (1)
        def result =
            new ImmutableVideo(
                name: "${video2Process.name}-processed",
                type: "ogg"
            )
    then: 'no exception is thrown even if it was a null ref'
        notThrown(NullPointerException)
    and: 'transformation has been applied'
        result.name?.contains('processed')
        result.type == 'ogg'
    where: 'possible values are'
        video << [
            null,
            new Video(name: 'documentary.mp4', type: 'mp4')
        ]
}
Introducing Optional pattern
void 'Using Optional pattern: dealing with nulls'() {
    when: 'creating default reference'
        Option<ImmutableVideo> result =
            Option
                .from(video) (1)
                .map { ImmutableVideo v -> (2)
                    new ImmutableVideo(
                        name: "${v.name}-processed",
                        type: v.type)
                }
    then: 'no exception is thrown even if it was a null ref'
        notThrown(NullPointerException)
and: 'transformation has been applied'
    result.hasValue() == hasValue
    where: 'possible values are'
        video                                                        | hasValue
            new ImmutableVideo(name: 'documentary.mp4', type: 'mp4') | true
            null                                                     | false
}

7. Functional Patterns

(TODO)

8. Functional Abstractions

8.1. Introduction

Category Theory is a huge topic not related per se to programming, but nowadays is the basis of what functional programming has become today.

In this chapter I’ll try to explain and give examples of some terms taken from Category Theory and why they could be useful to us as programmers in our daily work.

Many of the examples are based on Haskell programming language. As a pure functional language is the best place if you want to learn the basis of functional programming, and also because there aren’t much documentation out there other than Haskell. Here you have my two cents :)

I’m aware that terms like Functor, Monad…​etc seem to be something strange, odd, difficult for most of the programmers born in the OOP era (including myself by the way).

I know it’s difficult…​ bad news: it becomes harder along the way, good news …​ there is no good news. I’m jocking good news is that the more you learn about Category Theory applied to functional programming the more you understand how to use functional programming at work…​ but stop! it’s about time…​ LETS DO THIS

8.2. Monoids

Please stick this into your mind…​A monoid…​.IS NOT A MONAD!!!! I wish it was, monads would be a lot easier to understand, A monoid is a very simple concept, simple and yet powerful…​we’ll see later on why. Lets see formal description first.

…​a monoid is an algebraic structure with a single associative binary operation and an identity element.

Ok so imagine we’ve got a set of numbers called V and a binary operation such as V x VV then V with * is a monoid if satisfies the following axioms:

associativity
\$AA a,b,c in V, (a*b) * c = a * (b*c)\$

That means that you can combine elements from that set, using that operation, in any order. Lets think about coding…​ you can build a code module as a combination of smaller computations. And because those computations can be executed in any order, they could be executed in parallel as well and finally combine the results of all of them.

Monoid
@Immutable (1)
@EqualsAndHashCode (2)
class V {
    int x, y

    (3)
    def plus(final V v) {
        return new V (x: x + v.x, y: y + v.y)
    }
}
1 We will be declaring as immutable all possible objects in order to apply best practices when trying to use those objects in a multi-threaded environment
2 We’are implementing equals() and hashCode() to know which object is which
3 Defining our binary operation

Here we just defined an object declaring a simple binary operation which is the sum of two given CarFleet objects.

Monoids: associativity
void 'simple monoid: associativity'() {
    given: 'three different entries'
        def a = new V(x: 1, y: 2)
        def b = new V(x: 1, y: 3)
        def c = new V(x: 1, y: 4)
    expect: 'applying binaryOp'
        ((a + b) + c) == (a + (b + c))
}
1 Applying the operation in a sequential manner.
2 Applying the operation in no order at all, or at least in a way we cannot predict the order.
identity element
\$\exists e in V, AA a in V, e * a = a * e = a\$

Keep in mind that the indentity element could be anything. It’s not the number one neccesarily, but something that doesn’t alter the element operated with it.

Monoids: identity
void 'simple monoid: identity'() {
    given: 'three different entries'
        def a = new V(x: 1, y: 200)
        def e = new V(x: 0, y: 0)
    expect: 'applying binaryOp'
        (e + a) == (a + e)
        (e + a) == a
        (a + e) == a
}

You may be wondering why should you bother about building an object like that and having such operations obeying that kind of rules…​ well associativity comes handy when talking about parallelism. If it doesn’t really matter in which order operations are executed, then you can scatter those operations through the available cores in your computer.

Monoids: parallelism
void 'simple monoid: parallelism'() {
    given: 'three different entries'
        def a = new V(x: 1, y: 2)
        def b = new V(x: 1, y: 3)
        def c = new V(x: 1, y: 4)
    when: 'applying binaryOp in order'
        def result1 = [a, b, c].sum() (1)
    and: 'applying in any order'
        def result2 = withPool { [a,b,c].sumParallel() } (2)
    then: 'both results should match'
        result1 == result2
}
1 Sum is executed in order
2 Sum is executed in parallel (no specific order can be assumed)

8.3. Functor

In Category Theory a Functor is a mapping between categories…​WHaAaAAAaaTT?? O_o

A Functor represents a container/wrapper of some sort, along with the ability to apply a function to elements wrapped in the container.

Ok, so a Functor is like a container, like a box. It contains a value. That value can be transformed by functions applied to the container, not to the value directly.

The formal definition of a Functor in Haskell is:

Functor definition
class Functor f where
    fmap :: (a -> b) -> f a -> f b

What does it mean ? Well it means that in order to build a new instance of a Functor type the type should implement a fmap method.

The fmap method receives a function (a -> b) which transforms an object of type a in another object of type b, it also receives a Functor of type a and finally returns a functor of type b.

How could we implement this ?

8.3.1. Example

Functor (Java)
package groovyfp.categories;

/**
 *
 * @param <A>
 */
public interface Functor<A> {
    public <B, F extends Functor<B>> F fmap(Function<A,B> fn);
}
Some of the interfaces or classes shown here are implemented in plain Java™. I’m planning to migrate them to Groovy 2.3+ with @CompileStatic any time soon.

So basically a functor allows us to transform the contained value applying a function. There’re some differences between the Java™ implementation and the Haskell one.

  • (a->b) becomes Function<A,B>

  • fa parameter will be the instance of the functor itself

  • fb becomes Functor<B>

Now imagine we had a function adding 3 to any number. In Haskell we would be seeing this:

Haskell example
fmap (+3) (Just 1)

I’ll try to reproduce the same behavior, this time with Groovy :) We will be following these steps:

  • We need a function receiving a number and returning a number (a->b)

  • Then the functor will receive the function and will know how to unwrap the value and after applying the function how to wrap it again.

8.3.2. Function (a→b)

A function represents a transformation applied to a given input, giving a certain result.

We need a function adding 3 to any given number. Here is a simple java interface defining a function:

Function (Java)
package groovyfp.categories;

/**
 *
 */
public interface Function<A,B> {
    B apply(A input);
}

Because this interface is in fact a functional interface, it could be substituted by a Closure expression. So instead of building a new class or building a verbose inner class implementation we will be using a closure to define a new implementation of the Function interface.

Function<Integer,Integer>
void 'Building a simple function'() {
    given: 'a function instance using closures'
        Function<Integer,Integer> plus_3 = { Integer v ->
            v + 3
        } as Function<Integer,Integer>
    when:  'using it'
        Integer result = plus_3.apply(5)
    then: 'the value to be the number plus 3'
        result == 8
}
Be aware that because closures only declare the return type you should add the type to the closure parameter if you care about input type.

8.3.3. Functor<A>

Well now we need an instance of a functor of type A, pass to the functor our previously created function and expect to receive a certain value with a certain type.

Functor<Integer>
void 'applying a given function to a functor'() {
    given: 'a function'
        Function<Integer,Integer> plus_3 = { Integer v -> v + 3 }
    and: 'a functor implementation. This time Maybe.Just implements functor'
        Functor<Integer> boxOfFive = Maybe.just(5)
    when: 'applying the function to functor to get another functor'
        Functor<Integer> result = boxOfFive.fmap(plus_3)
    then: 'the result should be the expected'
        result.typedRef.value == 8
}

Ok but how Maybe.Just gets something and transform it to another functor. Lets see what the fmap implementation does:

Maybe Functor#fmap implementation
@Override
public <B, F extends Functor<B>> F fmap(Function<JUST, B> fn) {
    return (F) just(fn.apply(this.getTypedRef().getValue()));
}

First I’ll try to describe which types are involved:

  • JUST is the value contained by the Maybe instance (which among other things is a functor).

  • <B> is the type of the function applied. Then the Maybe implementation wraps that value into another instance of a functor (this time another Just instance).

Basically here the fmap method takes as an argument a function transforming the contained value in the source functor and then wraps it again in another functor instance.

By the way, althought fmap is implemented in Functor in languages like Haskell, you won’t see fmap being invoked like "myObject.fmap(…​)" but instead you will find something like fmap(functor, function)

In the source code you will see that there’re several methods adding some syntactic sugar to inner functors/applicative/monads methods mimicking the way Haskell does it.

Public API
import static groovyfp.categories.Fn.val
import static groovyfp.categories.Fn.fmap
Functor<Integer>
void 'applying a given function to a functor with public api'() {
    when: 'using fmap function to execute the fmap method from Just'
        Functor<Integer> result =
            fmap(Maybe.just(5)) { Integer x ->
                x + 3
            }
    then: 'executing val() to get Just inner value'
        val(result) == 8
}

8.3.4. Plain Groovy

Well under the hood many of the methods added to the Groovy API (api, gapi, gdk) resemble monadic behaviors. For example there is the with method all Groovy objects have. Although it could be seen more like a bind action (we’ll cover it later on) we can create a lighter version of fmap with this with.

Groovy map
def map(Object o, Closure function) {
    o?.with(function)
}

As we’ll see later on, many monadic estructures don’t execute functions when they detect something went wrong, or the type at a hand means nothing can be executed (a Maybe.Nothing , Either.Left value, or a Try.Failure values could be an example for that)

This with on steroids executes the closure (function) passed as parameter when the value exists (and represents a Groovy truth of couse ;) ). Notice was achieved by using the safe operator from Groovy (foo?.unsafeMethod()).

Groovy map
void 'Groovy light version of fmap'() {
    when: 'using fmap function to execute the fmap method from Just'
        def result = map(input) { Integer x ->
            map(x + 3) { Integer y ->
                y
            }
        }
    then: 'executing val() to get Just inner value'
        result == expected // 8 and null
    where:
        input    | expected
            5    | 8
            null | null
}

And I can’t finish this section without talking about collect. Collect is the closest version of fmap I can think about within Groovy. Collect transforms each item in a collection into something else.

Same way our map method was safe so is collect.

Groovy collect
void 'Groovy collect is "similar" to fmap'() {
    when: 'Applying a function to collect'
        def result =
            input.collect { Integer x ->
                x + 1
            }
    then: 'checking'
        result == expected
    where: 'possible messy values'
        input     | expected
            [1,2] | [2,3]
            null  | []
}

So…​ why don’t we make a better world and use both ideas combined ?

Groovy collect
void 'Groovy light version of fmap and collect combined'() {
    when: 'Making the world a safer place'
        def result =
            input.collect { Integer x ->
                map(x) { Integer y ->
                    (y + 1) * 2
                }
            }
    then: 'checking'
        result == expected
    where: 'possible messy values are'
        input         | expected
            [1, 2]    | [4, 6]
            [1, null] | [4,null]
}

8.4. Applicative Functor

Remember I was saying a Functor is a container, a box if you like, containing a simple value ? You can think about Applicative like a Functor containing a Function. This time the box contains a Function.

Why then the name of Applicative ? I’m not quite sure, but I think it came from the idea that a function can be applied to some other values.

In Haskell:

(<*>) :: Applicative f => f (a->b) -> (f a -> f b)

This time instead of containing a plain value the functor has a function. So we can read the Haskell function as a function receiving an applicative f (a->b) (a functor containing a function transforming from a to b) and returns the transformation from a functor containing a to a functor containing b (f a -> f b).

8.4.1. Example

package groovyfp.categories;

/**
 *
 * @param <A>
 */
public interface Applicative<A> extends Functor<A> {
    public <U extends Type<A>> U getTypedRef();
    public <B> Applicative<B> fapply(Applicative<Function<A,B>> afn);
}

We have included in our Java™ version a way of accessing the inner value forcing any Applicative to implement the getValue() method.

Instead of getValue returning a raw value I’ve implemented getTypedRef which returns a wrapper having the raw instance. I did it becauseI didn’t found a solution to resolve the problem of having the ListMonad sharing the same interface with Monads sharing single values and still respecting the fmap, fapply and bind methods. I’m not perfect so I will be very happy if someone gives me a better solution :)

But the most important method is fapply which in in charge of receiving another applicative and use the value of that applicative and apply it to the inner value of the instance of the source applicative.

Lets take a look to the implementation of the fapply method in the Maybe.Right class we can see how it works.

@Override
public <B> Just<B> fapply(Applicative<Function<JUST, B>> afn) {
    return this.fmap(afn.getTypedRef().getValue());
}

How can we use it ?

In this example I’m using implementations of Maybe. This implementation is not only an Applicative but a Functor (which is implied) and a Monad. Instead of creating object with new operator every object has a static method to do it.

import static Maybe.just
import static Maybe.nothing
import groovyfp.categories.Maybe.Nothing

This is the example:

void 'Applicative: Maybe applicative implementation'() {
    when: 'combining two closures'
        def inc = { Integer v -> v + 1 }
        def byTwo = { Integer v -> v * 2 }
    and: 'using the combination as a Function'
        def combination = (inc >> byTwo) as Function
    then: 'if the value is nothing the function shouldnt be applied'
        nothing().fapply(just(combination)).typedRef.value == null (1)
    and: 'otherwise if the initial value is correct the function will work'
        just(1).fapply(just(combination)).typedRef.value == 4 (2)
}
1 The implementation of the Maybe.Nothing fapply method doesn’t apply the function to the current instance and returns an instance of new Nothing(null)
2 The implementation of the Maybe.Just fapply method applies current value to the function contained within the Applicative passed as parameter.

8.5. Monad

What is a Monad ?

While Functor applied a function to a wrapped value, and an Applicative applied a wrapped function to a wrapped value, a Monad applies a function to a wrapped value and returns a wrapped value.

Because Monad is an Applicative and an Applicative is a Functor, likewise a Monad has some inherit methods such as fmap or fapply. But the method that makes a Monad a Monad is the bind method (or >>= which is its alias in Haskell).

How does bind looks like ? Like always , first step, Haskell syntax:

class Monad m where
    (>>=) :: m a -> (a -> m b) -> m b

A bind method receives a wrapped value m a then a function (a -> m b) which transforms the wrapped value to another wrapped value, and finally returns the transformation result m b.

In my humble representation of a Monad type in Java™ I came up with the following code:

package groovyfp.categories;

/**
 *
 * @param <A>
 */
public interface Monad<A> extends Applicative<A> {
    public <B,M extends Monad<B>> M bind(Function<A,M> fn);
}

8.5.1. Maybe

The Maybe is normally used to avoid asking whether the value is null or it can contain any value. That’s why the Maybe object has two children: Maybe.Just and Maybe.Nothing.

In the JDK 8 you can find the Optional type. Sometimes is also called Option.

As we’ll be seeing along this chapter is that monads like Maybe, Either or ListMonad will allow to apply functions over the wrapped value, only if the wrapped value is considered valid. Otherwise the wrapped value will be returned.

To see how to use Maybe lets use it in a simple exercise:

Given a number, I want to divide it by half two times, and then if still not decimal, multiplied by three.

Because all even numbers will become decimals as soon as I try to dividing them by half I want to stop the process as soon as the process detects that number is no longer eligible to success.

void 'Monad: using maybe to shortcircuit a process'() {
    given: 'a function dividing only even numbers'
        def half = { BigDecimal possible ->
            return possible.intValue() % 2 == 0 ?
                Maybe.just(possible.div(2)) :
                Maybe.nothing()
        }
    and: 'another function multiplying by three'
        def threeTimes = { BigDecimal possible ->
            return Maybe.just(possible * 3)
        }
    when: 'starting the process'
        Integer result =
            Maybe.just(sampleNumber)
                .bind(half) (1)
                .bind(half) (2)
                .bind(threeTimes) (3)
                .typedRef.value
    then: 'checking the result'
        result == expected
    where: 'sample numbers and expectations are'
        sampleNumber | expected
            100      |    75
            200      |   150
             50      |   null
}
1 tries to divide, if not even returns nothing otherwise returns division result.
2 tries again to divide the number under the same premises.
3 If division ended successfully only then applies multiplication.

The nice thing about this plan is that if any of the previous steps ended with a Maybe.Nothing instance the process won’t go any further.

In order to understand what happens underneath, why process doesn’t continue, I would like to show you both implementation of Maybe.Just and Maybe.Nothing.

While Maybe.Just applies the function:

@Override
public <B, M extends Monad<B>> M bind(Function<JUST, M> fn) {
    return fn.apply(getTypedRef().getValue());
}

Maybe.Nothing like its name, does nothing but to return the current value :P

@Override
public <B, F extends Functor<B>> F fmap(Function<NOTHING, B> fn) {
    return (F) new Nothing();
}

Sometimes it would be useful to have an alternative when there’s no value. That’s what the method or does. It makes the monad to return the alternative value in case there was no value. Otherwise the current value is returned.

void 'testing maybe alternatives (I)'() {
    when: 'something has no value and adding an alternative'
        Maybe<String> name = nothing().or(just("john"))
    then: 'we should get the alternative'
        name.typedRef.value == 'john'
}

It’s pretty clear in the previous example, but it is even clearer when you do something ( a transformation for example) with the current inner value.

void 'testing maybe alternatives (III)'() {
    when: 'something has value and adding an alternative'
        Maybe<Integer> nameLength =
            just("mario")
                .bind { nothing() } // some fancy logic here
                .or(just(0))
    then: 'we should get first value'
        nameLength.typedRef.value == 0
}

8.5.2. Either

Either monad is also one of the classics. The Either monad instance can represent correct or error.

As imperative programmer I’m used to choose between branches in my code using conditional structures such as if. As Groovy programmer I’ve gone one step further and I’ve met the Groovy Truth that helps me a lot classifying instances between those which could be seen as a false statement and those which can be taken as a true statement.

But what if we go beyond ? What if we had a type saying it could be right or wrong depending on its own but still having content ?.

The following example tries to search certain type of people from a given list. The search will stop once a person has been found with any of the given rules.

void 'using Either to chain failback searchs'() {
    given:'a base function to search by a certain criteria'
        def baseSearch = { Closure<Boolean> search -> (1)
            return { List sample ->
                def pr = sample.find(search)
                // if found then return left to shortcircuit further
                // searchs
                pr ? Either.left(pr) : Either.right(sample)
            }
        }
    and: 'composed criterias on top of the base function'
        // they become Function<A,Monad<B>>
        def lookByNameJohn = baseSearch { it.name == 'john' } (2)
        def lookByAgeGreaterThan = baseSearch { it.age > 50 }
        def lookByCity = baseSearch { it.city == 'dublin' }
    when: 'chaining all search criterias'
        Either result = (3)
            Either.right(sample)
                .bind(lookByNameJohn)
                .bind(lookByAgeGreaterThan)
                .bind(lookByCity)
    then: 'there should be only one item'
        result.isLeft()
        result.typedRef.value.name == name_of_the_result
    where: 'samples used in this spec are'
        sample          |   name_of_the_result
        firstSample     |       'john'
        secondSample    |       'peter'
        thirdSample     |       'rob'
}

First of all, I need to apologise because in this example It seems I’ve used Either just to do the opposite. This time think Either.Left as something telling us to stop looking because we’ve found what we were looking for.

1 baseSearch is a function that returns another function. That inner function returns an Either.Left instance with the result inside if the search function passed as parameter succeeded. I want the function to return Either.Left because I know when an Either.Left is returned no further action is done. And because I’ve found what I was looking for, I don’t want the search to go any further.
2 I’ve created three different functions valid to be used in an fmap function. That means they receive an unwrapped value but they will return a wrapped value.
3 Given the source we will try to apply three types of search in order to find someone. Because the rules of the monad, I know if the first search fails the second will be triggered, and so on. In case any of them succeed the value will be return immediately.

8.5.3. ListMonad

Collections in general are one of the most used data structures ever. Some languages use collections only as data structures and some others make them implement monadic semantics in order to be able to do things like list comprehensions.

According to Wikipedia a list comprehension is:

A list comprehension is a syntactic construct available in some programming languages for creating a list based on existing lists

— Wikipedia

I would add that implementations differ in which are capable of handling streams and those which don’t.

First of all I’m would like to start with a basic finite example. Like we did before, lets sneak a little bit on how Haskell does it ;)

(TODO)

8.5.4. Try

Nowadays JVM languages deal with exceptions using try-catch blocks. The problem is that these constructions force programmers to build their code in a certain way.

Try monad wraps the result of a given computation. That computation could either end on a desired value, having an instance of Success, or could throw an exception, having an instance of Failure instead.

Like Either, composition has a special importance here, due to the fact that when having a Failure instance all possible actions applied over it will always return the same failure.

This first example tries to parse an invalid number and add one to it.

Parse a possible number
def 'parsing a non valid number: Try'() {
    when: 'trying to parse a non valid number'
        Function inc = { x -> x + 1 }
        Try result1 = Try { Integer.parseInt("2a")} (1)
        Try result2 = fmap(result1, inc) (2)
    then: 'computation failed'
        result1.isFailure()
    and: 'any possible composition will return the same failure'
        result2.isFailure()
}

Here we can see both behaviors.

1 First of all the given function fails and the instance returned is an instance of Failure we know that because only Failure instances return true when calling to isFailure() method.
2 Besides that we can also notice that using a failure instance to create further function composition will end returning the same failure, which is the same as saying that no further function will ever succeed using that failure.

When having a Failure instance, the exception that caused it is also wrapped within the instance, and you could whether get it to inspect it, or throw it like any other exception.

throwException
def 'throwing an exception'() {
    when: 'doing something wrong'
        Try.Failure failure = Try { 0.div(0) }
        (1)
        assert failure.exception instanceof ArithmeticException
    and: 'wants to propagate the exception'
        failure.throwException() (2)
    then:'the exception will be thrown as usual'
        thrown(ArithmeticException)
}
1 You can get the wrapped exception
2 Or throw the exception instead

Normally when having an exception we would like to react somehow. Sometimes we may want to set, for example a default value in case something went wrong.

In our example I would like to get zero in case the number was not valid. Then I would like to add one to that given number.

TryOrElse
def 'reacting with TryElse'() {
    given: 'the functions used in this example'
        def returnZero = { 0 }
        def increment = { Integer x -> x + 1 }
        def parseInt = { String number ->
            return {
               Integer.parseInt(number)
            }
        }
    when: 'trying to parse any type of value'
        Try result =
            fmap(
                TryOrElse( (1)
                    parseInt(next),
                    returnZero
                ),
                increment)
    then:'the value should always be greater than 0'
        val(result) >= 1
    where: 'values can be valid or invalid'
        next << ["1","2a","3"]
}
1 You can notice how we use TryOrElse to react when the main action failed. Then the second action will be executed instead. I think this is a very common scenario and this way of coding could be very useful and descriptive.

Of course, if the alternative function fails the TryOrElse execution will return a Failure instance anyway. So, the next question could be: Is there any way of recovering from a failure instance once we’ve executed both main and alternative actions ?

Well there is the recover() method. This method has two arguments the possible Failure instance, and the Success instance to use instead.

recover()
def 'using recover()'() {
    when: 'you cant always get what you want'
        Try something =
            TryOrElse(
                { 0.div(0) }, // WRONG
                { new Date() + "1" } // WORST
            )
        Try anything = recover(something, Try { 0 })
    then: 'you can always get what you need :P'
        val(anything) == 0

}

9. Persistent collections

(TODO)