Towards a Better Understanding of CAR, CDR, CADR and the Others

This paper describes the IBM 704 architecture and the genesis of the names for CAR, and CDR, which, as it turns out, probably don’t quite make sense. The paper suggests that this may not be all bad, as the names lend themselves to compounding. Indeed that the compound function names , such as CADR, or even CADADR, etc. may be read as little access programs.

💡 Research Summary

The paper provides a thorough historical and technical investigation into the origins of the Lisp primitive functions CAR, CDR, and their compounded forms such as CADR and CADADR. It begins by describing the architecture of the IBM 704, a pioneering 36‑bit computer introduced in 1954. The IBM 704’s word format contained both an address field and a data field within a single 36‑bit word, and its instruction set required programmers to manipulate these fields explicitly. Because high‑level languages were not yet available, early programmers had to devise their own mechanisms for handling complex data structures like linked lists directly on the hardware.

John McCarthy, the creator of Lisp, leveraged this hardware layout to define two fundamental list operations. He named the operation that returns the first element of a list “CAR” and the operation that returns the remainder of the list “CDR”. The paper argues that these names were not official IBM terminology but rather ad‑hoc abbreviations derived from the IBM 704’s internal nomenclature: CAR as “Contents of the Address part of Register” and CDR as “Contents of the Data part of Register” (or, in some accounts, “Contents of the Decrement part of Register”). The authors show that the IBM 704 manuals contain no explicit definition of these acronyms, confirming that they emerged organically from the needs of early Lisp implementers.

Beyond their individual meanings, CAR and CDR became the building blocks for a powerful compositional naming scheme. By concatenating the letters, programmers could express arbitrarily deep list traversals: CADR means “CAR of CDR”, CADADR means “CAR of CDR of CAR of CDR”, and so on. The paper demonstrates that this compounding yields concise “little access programs” that are both human‑readable and mechanically reducible, a property that has persisted in later Lisp dialects such as Scheme, Clojure, and Racket.

The authors also examine how the physical constraints of the IBM 704 shaped this naming convention. The necessity to distinguish between address and data portions within a single word, combined with a limited number of registers, forced early programmers to think in terms of “address‑part contents” and “data‑part contents”. This hardware‑driven mental model directly inspired the CAR/CDR terminology and, by extension, the entire family of compounded accessors.

From a broader perspective, the paper argues that understanding this historical context offers valuable lessons for modern language designers. First, hardware realities can leave a lasting imprint on language abstractions; recognizing this can guide the creation of more natural APIs when new architectures emerge. Second, concise, composable function names dramatically improve code readability and encourage a functional style that emphasizes higher‑order composition. Third, correcting historical misconceptions about the etymology of widely used terms reinforces scholarly rigor and can inspire fresh naming strategies that better reflect contemporary architectures.

In conclusion, the IBM 704’s word layout and instruction set were not merely technical footnotes but the seed from which the iconic CAR/CDR family grew. Their evolution illustrates how low‑level constraints can give rise to high‑level abstractions that endure for decades. By tracing this lineage, the paper highlights the interplay between hardware design, early software engineering decisions, and the enduring principles of composability and readability that continue to shape functional programming today.