What are algebraic structures in functional programming?

Question

I've been doing some light reading on functional programming concepts and ideas. So far, so good, I've read about three main concepts: algebraic structures, type classes, and algebraic data types. I have a fairly good understanding of what algebraic data types are. I think sum types and product types are fairly straightforward. For example, I can imagine creating an algebraic data type like a Card type which is a product type consisting of two enum types, Suit (with four values and symbols) and Rank (with 13 values and symbols).

However, I'm still hung up on trying to understand precisely what algebraic structures and type classes are. I just have a surface-level picture in my head but can't quite completely wrap my head around, for instance, the different types of algebraic structures like functors, monoids, monads, etc. How exactly are these different? How can they be used in a programming setting? How are type classes different from regular classes? Can anyone at least point me in the direction of a good book on abstract algebra and functional programming? Someone recommended I learn Haskell but do I really need to learn Haskell in order to understand functional programming?

Answer 1

"algebraic structure" is a concept that goes well beyond programming, it belongs to mathematics.

Imagine the unfathomably deep sea of all possible mathematical objects. Numbers of every stripe (the naturals , the reals , p-adic numbers...) are there, but also things like sequences of letters, graphs , trees , symmetries of geometrical figures , and all well-defined transformations and mappings between them. And much else.

We can try to "throw a net" into this sea and retain only some of those entities, by specifying conditions. Like "collections of things, for which there is an operation that combines two of those things into a third thing of the same type, and for which the operation is associative". We can give those conditions their own name, like, say, "semigroup" . (Because we are talking about highly abstract stuff, choosing a descriptive name is difficult.)

That leaves out many inhabitants of the mathematical "sea", but the description still fits a lot of them! Many collections of things are semigroups. The natural numbers with the multiplication operation for example, but also non-empty lists of letters with concatenation, or the symmetries of a square with composition .

You can expand your description with extra conditions. Like "a semigroup, and there's also an element such that combining it with any other element gives the other element, unchanged". That restricts the number of mathematical entities that fit the description, because you are demanding more of them. Some valid semigroups will lack that "neutral element" . But a lot of mathematical entities will still satisfy the expanded description. If you aren't careful, you can declare conditions so restrictive that no possible mathematical entity can actually fit them! At other times, you can be so precise that only one entity fits them.

Working purely with these descriptions of mathematical entities, using only the general properties we require of them, we can obtain unexpected results about them, non-obvious at first sight, results that will apply to all entities which fit the description. Think of these discoveries as the mathematical equivalent of "code reuse". For example, if we know that some collection of things is a semigroup, then we can calculate exponentials using binary exponentiation instead of tediously combining a thing with itself n times. But that only works because of the associative property of the semigroup operation.

Answer 2

You've asked quite a few questions here, but I can try to answer them as best I can:

… different types of algebraic structures like functors, monoids, monads, etc. How exactly are these different? How can they be used in a programming setting?

This is a very common question when learning Haskell. I won't write yet another answer here — and a complete answer is fairly long anyway — but a simple Google search gives some very good answers: eg I can recommend 1 2 3

How are type classes different from regular classes?

(By 'regular classes' I assume you mean classes as found in OOP.)

This is another common question. Basically, the two have almost nothing in common except the name. A class in OOP is a combination of fields and methods . Classes are used by creating instances of that class; each instance can store data in its fields, and manipulate that data using its methods.

By contrast, a type class is simply a collection of functions (often also called methods , though there's pretty much no connection). You can declare an instance of a type class for a data type (again, no connection) by redefining each method of the class for that type, after which you may use the methods with that type. For instance, the Eq class looks like this:

class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool

And you can define an instance of that class for, say, Bool , by implementing each function:

instance Eq Bool where
    True == True   = True
    False == False = True
    _ == _         = False

    p /= q = not (p == q)

Can anyone at least point me in the direction of a good book on abstract algebra and functional programming?

I must admit that I can't help with this (and it's off-topic for Stack Overflow anyway).

Someone recommended I learn Haskell but do I really need to learn Haskell in order to understand functional programming?

No, you don't — you can learn functional programming from any functional language, including Lisp (particularly Scheme dialects), OCaml, F#, Elm, Scala etc. Haskell happens to be a particularly 'pure' functional programming language, and I would recommend it as well, but if you just want to learn and understand functional programming then any one of those will do.