In a recent blog post, Edward Z. Yang talks about applicative functors.
He mentions two equivalent definitions of applicative functors - the standard
definition used in Haskell libraries (
Applicative) and an alternative that
has been also presented in the original paper, but is generally less
The standard definition makes a perfect sense with the standard uses in Haskell,
however I always preferred the alternative definition. Edward uses the alternative
Monoidal) definition to explain the laws that should hold about applicative
functors and to explain commutative applicative functors, but I think it
is even more useful.
Monoidal definition fits nicely with a trick that you can use to
encode applicative functors in C# using LINQ and I also used it as
a basis for an F# syntax extension that allows writing code using applicative
functors in a similar style as using monads (which is discussed in my draft
paper about writing abstract computations in F#). And I also think that
commutative applicative functors deserve more attention.
Using functional programming language changes the way you write code in a number of ways. Many of the changes are at a small-scale. For example, you learn how to express computations in a shorter, more declarative way using higher-order functions. However, there are also many changes at a large-scale. The most notable one is that, when designing a program, you start thinking about the (data) types that represent the data your code works with.
In this article, I describe this approach. Since the acronym TDD is already taken, I call the approach Type-First Development (TFD), which is probably a better name anyway. The development is not driven by types. It starts with types, but the rest of the implementation can still use test-driven development for the implementation.
This article demonstrates the approach using a case study from a real life: My example is a project that I started working on with a friend who needed a system to log journeys with a company car (for expense reports). Using the type-first approach made it easier to understand and discuss the problem.
In many ways, TFD is a very simple approach, so this article just gives a name to a practice that is quite common among functional and F# programmers (and we have been teaching it at our F# trainings for the last year)...
Similarly to the last year, I already have a number of F# events planned for the end of the summer and autumn that I'd like to invite you to!
The Visual Studio 2012 has been completed recently and it comes with F# 3.0. For me, this means two things. Firstly, it is the second Visual Studio version of F#, which means that functional programming is worth taking seriously. Secondly, F# 3.0 comes with type providers, which is a killer feature for working with data. No matter if you're a C# programmer now to functional programming or if you're an F# user in the real-world, I hope you can find some interesting and useful event below!
The two main things that I'm going to be involved in are SkilsMatter trainings in London and New York and a few events at the biggest functional conference (ICFP) in Copenhagen...