What we talk about when we talk about monads

Abstract

Computer science provides an in-depth understanding of technical aspects of programming concepts, but if we want to understand how programming concepts evolve, how programmers think and talk about them and how they are used in practice, we need to consider a broader perspective that includes historical, philosophical and cognitive aspects. In this paper, we develop such broader understanding of monads, a programming concept that has an infamous formal definition, syntactic support in several programming languages and a reputation for being elegant and powerful, but also intimidating and difficult to grasp. This paper is not a monad tutorial. It will not tell you what a monad is. Instead, it helps you understand how computer scientists and programmers talk about monads and why they do so. To answer these questions, we review the history of monads in the context of programming and study the development through the perspectives of philosophy of science, philosophy of mathematics and cognitive sciences.More generally, we present a framework for understanding programming concepts that considers them at three levels: formal, metaphorical and implementation. We base such observations on established results about the scientific method and mathematical entities -cognitive sciences suggest that the metaphors used when thinking about monads are more important than widely accepted, while philosophy of science explains how the research paradigm from which monads originate influences and restricts their use.Finally, we provide evidence for why a broader philosophical, sociological look at programming concepts should be of interest for programmers. It lets us understand programming concepts better and, fundamentally, choose more appropriate abstractions as illustrated in a number of case studies that conclude the paper. ACM CCS 2012General and reference → Surveys and overviews; Social and professional topics → History of computing;

High-Level Modelling for Typed Functional Programming

“…Since all names have a meaning which must necessarily exist for them to be used within their language-game, it makes no sense to talk about whether a name "exists" or not (50, 57, 58). The meaning behind a name, and how to use it, must necessarily be known before a name is defined (31). Similarly to names, all words in a language game are ways to represent other things (50).…”

“…Ironically, these constructs can also be formidable barriers to understanding. The fundamental issue, covered well in [31], is subtle but pervasive throughout typed functional programming: abstract knowledge of parametrically polymorphic functions and the transformations that they potentially enable is not sufficient to combine them sensibly or construct a cohesive narrative from them. The typed functional programming domain has many ways to describe functions and transformations (lambda, higher-order, functor, applicative, arrow, ...) but no way to describe how to link these into a cohesive narrative.…”

Kaemika App: Integrating Protocols and Chemical Simulation

“…We then use nominal semantics [6] to deal with the generation and lexical binding of an unbounded number of unique chemical species ("If I create new species inside a loop, can I plot them?"). Finally we use an output monad [11], which is a somewhat grandiose but systematic scheme for generating a network of chemical reactions from a functional computation ("Can I produce a network whose size is determined by conditional execution?"). All answers are "yes!…”