Algebraic structures are a cornerstone of typed functional programming, but they can be intimidating when first encountered. The most commonly mentioned ones, functors, applicatives, and monads, are often introduced with some combination of Haskell code, abstract math, or fuzzy analogies. This blog series is my attempt at introducing these concepts in a rigorous but accessible way. The posts here don’t make use of abstract math or category theory, and assume no familiarity with functional programming other than a very basic understanding of higher-order functions and currying. …

*Click here to share this article on LinkedIn »*

*I’ve moved my blog. You can view this article’s new home on my personal website **here**.*

In my last post I said that there were three fundamental approaches to representing data: abstract data types, objects, and algebraic data types. I introduced abstract data types and objects (using a strict definition of “object” based on autognosis) and showed the tradeoffs of implementing data structures in these two styles. …

*I’ve moved my blog. The new version of this post, which uses TypeScript rather than Flow, may be viewed **here**.*

There are three main methods of representing data which developers are likely to encounter: abstract data types, algebraic data types, and objects. Abstract data types (frequently abbreviated “ADTs”) are likely familiar to developers with a computer science background, and algebraic data types (unfortunately also abbreviated “ADTs”) are likely familiar to developers with a functional programming background. Objects are a concept that most developers are extremely familiar with on a practical level, but many struggle to precisely define. These three approaches…

This is the final part of a three-part series on effectful programming with applicative functors. In the last two posts we’ve covered what computational effects are, and how we can use them in conjunction with applicative functors to capture side effects in functional code. In part one we did this to implement composable parsers; in part two we implemented a general applicative representing the effect of reading from an environment and used this to implement an evaluator for an AST representing arithmetic expressions. (If you have not read these posts, I recommend doing so before continuing with this one.)

In…

This is part two of a three-part series on effectful programming with applicative functors. In part one we saw that many imperative side effects can be encapsulated into well-behaved computational effects by modeling the side effect as a modification to state within a given context and then making this context into an applicative functor. We used this to implement a simple applicative parser, which provided the effects of consuming input and potentially failing, and saw that `liftA`

let us compose the effects of parsers in order to easily parse compound data structures. …

*This is part of my series on algebraic structures. The whole series can be seen **here**.*

In my last post I introduced applicative functors, and showed how they build on plain functors to allow us to apply pure functions to values inside of special contexts. This made our code more generic and composable by letting us specify our logic in pure functions and lift it into whatever context is needed using `liftA`

. This is not all there is to applicatives, though. There are many cases where our logic is inherently connected to a particular context, and where we may want…

In a previous post I talked about functors, data types which act as a context holding contents which can be mapped over. In this post I’ll talk about applicative functors, or “applicatives”, a subtype of functors for which additional functions are defined. In this post we’ll cover the core of applicatives: their interface, laws, some sample implementations, and their basic uses. This post requires familiarity with functors and currying, but doesn’t assume any other prior functional programming knowledge.

All of the examples in this post are written in JavaScript, using Flow type annotations.

Recall that functors can be thought of…

While they aren’t often discussed outside of the functional programming world, combinator libraries are a common and useful technique for building functional libraries. Their core characteristic is the construction of a small set of base functions and types, and a few higher-order functions for combining them. Most importantly, the functions produced by these higher-order functions are as composable as the base functions built into the library, and can be recombined with the library’s higher-order functions any number of times. This enables the creation of arbitrarily large and complex abstractions from a small number of simple pieces, while maintaining type safety…

*This is part of my **series on recursion schemes**.*

In the last two posts in this series we looked at catamorphisms, which collapse a nested data structure into a value, and anamorphisms, which build a nested data structure up from an initial seed value. If we combine the two, transforming one value into another by building up a recursive structure and then collapsing it back down, we have a hylomorphism. In this post we’ll look at the implementation of `hylo`

, the function which creates hylomorphisms, and see that it is more memory efficient than composing catamorphisms and anamorphisms directly. Then…

*This post is part of my **series on recursion schemes**.*

In the last post in this series we looked at catamorphisms, transformations that walk a recursive data structure from the bottom up, collapsing a functor to its contained type at each step. This time, we’ll be looking another type of transformations, anamorphisms. We’ll look at the implementation and functioning of `ana`

, (the function which creates anamorphisms,) a few example anamorphisms, and the relationship between anamorphisms and catamorphisms.

As we saw last time, catamorphisms are morphisms (transformations between two things), whose root “cata” (meaning down, back) reflects that they “tear down”…

JavaScript developer with a focus on typed functional programming. He/him. https://jnkr.tech