Thought I’d finish the Monad Tutorial since I stopped midway…

The general notion that the abstraction actually captures is the notion of dependency, the idea that an instance x of your type can be in some common operation dependent on other instances of your type. This common operation is captured in bind. For Promises for example, the common operation is “resolving”. In my first post, for the getPostAuthorName promise to resolve, you first need to resolve getPost, and then you need to resolve getUser.

It also captures the idea that the set of dependencies your x is not fixed, but can be dynamically extended based on the result of the operation on previous dependencies, e.g.:

const getPostAuthorName = async foo => {
  const post = await getPost(foo)
  if (post === undefined) return undefined
  const user = await getUser(post.authorId)
  return user.username
}

In this case, getPostAuthorName is not dependent on getUser if getPost already resolved to undefined. This naturally induces an extra order in your dependents. While some are independent and could theoretically be processed in parallel, the mere existence of others is dependent on each other and they cannot be processed in parallel. Thus the abstraction inherently induces a notion of sequentiality.

An even more general sister of Monad, Applicative, does away with this second notion of a dynamic set and requires the set of dependents to be fixed. This loses some programmer flexibility, but gains the ability to process all dependents in parallel.