Applicative-what? Functor-who?

[Part 1 of ..]

Going through the list of features available in the Haskell platform is both exciting and confusing. With just the first bullet point I’m already off the map with my programming experience at least with Haskell’s terminology. Why is it exciting to be confused? It means there’s an opportunity to learn something!

Here’s the first section of the Haskell Platform’s features:

Control Structures

• applicatives, arrows, functors, monoids
• synchronous and asynchronous (extensible) exceptions
• monads: the mtl monad suite
• foldables, traversables

Let’s follow the white rabbit starting with the heading, “Control Structures” and follow the trail of concepts with a lot of help from Wikipedia, which I’ll quote mercilessly and messily in the process of learning while explaining, or explaining while learning. Ok, ok, I’m explearning it here and it may take a few parts to capture it all.

Control Structures Ok, we expect things like IF/THEN, WHILE, FOR here but these are not language features from Haskell declarations/expressions, these are packages distributed with the library. The first one it lists are “applicatives.”

Applicatives A new concept for me, these turn out to be “applicative functors”, which also presents a new concept, “functors.”  I’ll have to come back to applicatives shortly.

Functors Are ‘a mathematical term that comes from Category Theory, defined as “a special type of mapping between categories.”‘ Yes, its another crumb on the trail that’ll have to be explained… you’ll be able to tell that Haskell has deep roots in higher mathematics.  Don’t let that scare you—because that only means that you need to learn a lot of terminology to specifically describe concepts.

Category Theory “an abstract way with mathematical structures and relationships between them: it abstracts from sets and functions respectively to objects linked in diagrams by morphisms or arrows.”  Aha! “arrows”, the second word in the first bullet point above.  So now we know that functor>applicatives are related to arrows via Category Theory.  I’ll assume that most programmers are already familar with sets, functions and objects and move on to the arrow (aka morphism).

Arrows Are “an abstraction derived from structure-preserving mappings between two mathematical structures.” Ok, a new term “mappings”–which turns out to be a synonym for function.  So we’ll re-describe arrows as ‘an abstraction derived from structure-preserving functions between two mathematical structures.’  Now we’re assuming that Haskell “computer science” is using the same terminology as “mathematics.”   Computer Scientists are notorious for borrowing terminology from other fields and using it in new ways with new meanings. We’d better check on that understanding of arrow between CS and higher math, first from Haskell’s CS POV:

Arrows are a new abstract view of computation, defined by John Hughes. They serve much the same purpose as monads — providing a common structure for libraries — but are more general. In particular they allow notions of computation that may be partially static (independent of the input) or may take multiple inputs. If your application works fine with monads, you might as well stick with them. But if you’re using a structure that’s very like a monad, but isn’t one, maybe it’s an arrow.

Ok, now we need to add monad to the concept mix to be able to compare them against arrows.  Monads are definitely a leap in thought so we’ll need a large chunk of text to digest:

Monads Are  a kind of abstract data type used to represent computations (instead of data in the domain model). Monads allow the programmer to chain actions together to build a pipeline, in which each action is decorated with additional processing rules provided by the monad. Programs written in functional style can make use of monads to structure procedures that include sequenced operations, or to define arbitrary control flows (like handling concurrency, continuations, or exceptions).

Formally, a monad is constructed by defining two operations (bind and return) and a type constructor M that must fulfill several properties to allow the correct composition ofmonadic functions (i.e. functions that use values from the monad as their arguments). The return operation takes a value from a plain type and puts it into a monadic container of type M. The bind operation performs the reverse process, extracting the original value from the container and passing it to the associated next function in the pipeline.

A programmer will compose monadic functions to define a data-processing pipeline. The monad acts as a framework, as it’s a reusable behavior that decides the order in which the specific monadic functions in the pipeline are called, and manages all the undercover work required by the computation. The bind and return operators interleaved in the pipeline will be executed after each monadic function returns control, and will take care of the particular aspects handled by the monad.

The name is taken from the mathematical monad construct in category theory.

That’s a dump truck of concepts to swallow.  Let’s grab the explanation of monad from category theory:

In category theory, a monad or triple is an (endo-)functor, together with two associated natural transformations. They are important in the theory of pairs of adjoint functors, and they generalize closure operators on partially ordered sets to arbitrary categories.

Don’t you get the feeling that you’re going to know just as much about category theory and Haskell by the time you reach the end of this? I do.  Lets list the concepts currently in play on the mental stack: monad, arrow, functor, applicative, and control structure.

So the monad is a datatype that represents the computation performed upon data as opposed to a type of data. For example a type of data we commonly use in programming would be a “number.”  A number just represents a scalar quantity of whatever meaning our program applies to it. So an example of a monad might be: moving data from one place to another. Next step is finding the similarities and differences between arrows and monads, but that’s for another day.

To Be Continued…