Groovy Applicatives

My last post discussed creating Functors in Groovy [5]. I demonstrated how to create a list functor. Before we start creating the applicative abstraction, let’s create a functor based on the rich FunctionalJava Option type to review functors and to later demonstrate applicatives.


Groovy Functors

Groovy and Java both provide abstractions that allow programmers to transform values within that abstraction. For example, Groovy provides the collect method on Collections and Java 8 provides the map method on the Stream class. This pattern is more widely applicable than these classes, however the simple Java type system prevents this idea from being expressed within Java.

If Java allowed this idea to be expressed it might be expressed as:

public interface Mappable<M<Z>> {
	public M<B> map(M<A> m, F<A, B> f);

Converting to JBake

This blog is being converted to JBake to allow easier workflow. As a result, some of the links will not be working, such as Disqus, the RSS feed and others.

Please keep this in mind as the conversion takes place. I am expecting this could take a week (around 2014-06-23).


Folds and Unfolds

Erik Meijer [4] has stated numerous times that "recursion is the goto of functional programming". In this post I investigate using folds and unfolds as a replacement for recursion. The work in this post has been added to FunctionalGroovy [5] as a Groovy extension module.


Referentially Transparent Input/Output in Groovy

When learning functional programming, a difficult concept to grasp is how any "actual work" gets done. That is, if all functions are referentially transparent, then how does the program perform IO (input/output), which is not typically referentially transparent? Are our functional programs locked out of IO, consigned to calculations without doing useful things like reading from the keyboard, printing to the screen, saving to disk or communicating over a network?

The answer, of course, is no. We create programs so that our entire program is a single IO action that, when run, can perform IO. Ideally, the program we write never actually runs any IO action, we rely on the runtime environment to run the single IO action representing our program. Most languages don’t have this environment; we compromise by making our main method run the single IO action representing the program.