The Ten Commandments
The First Commandment
When recurring on a list of atoms, lat, ask two questions about it: (null? lat) and else.
When recurring on a number, n, ask two questions about it: (zero? n) and else.
When recurring on a list of S-expressions, l, ask three questions about it: (null? l), (atom? (car l)), and else.
The Second Commandment
Use cons to build lists.
The Third Commandment
When building a list, describe the first typical element, and then cons it onto the natural recursion.
The Fourth Commandment
Always change at least one argument while recurring.
When recurring on a list of atoms, lat, use (cdr lat).
When recurring on a number, n, use (sub1 n).
And when recurring on a list of S-expressions, l, use (car l) and (cdr l) if neither (null? l) nor (atom? (car l)) are true.
It must be changed to be closer to termination.
The changing argument must be tested in the termination condition:
when using cdr, test termination with null? and when using sub1, test termination with zero?.
The Fifth Commandment
When building a value with +, always use o for the value of the terminating line, for adding 0 does not change the value of an addition.
When building a value with ✕, always use 1 for the value of the terminating line, for multiplying by 1 does not change the value of a multiplication.
When building a value with cons, always consider () for the value of the terminating line.
The Sixth Commandment
Simplify only after the function is correct.
The Seventh Commandment
Recur on the subparts that are of the same nature:
- On the sublists of a list.
- On the subexpressions of an arithmetic expression.
The Eighth Commandment
Use help functions to abastract from representations.
The Ninth Commandment
Abstract common patterns with a new function.
The Tenth Commandment
Build functions to collect more than one value at a time.
The Five Rules
The Law of Car
The primitive car is defined only for non-empty lists.
The Law of Cdr
The primitive cdr is defined only for non-empty lists.
The cdr of any non-empty list is always another list.
The Law of Cons
The primitive cons takes two arguments.
The second argument to cons must be a list.
The result is a list.
The Law of Null?
The primitive null? is defined only for lists.
The Law of Eq?
The primitive eq? takes two arguments.
Each must be a non-numeric atom.
Gerald Jay Sussman Foreword
In 1967 I took an introductory course in photography. Most of the students (including me) came into that course hoping to learn how to be creative — to take pictures like the ones I admired by artists such as Edward Weston. On the first day the teacher patiently explained the long list of technical skills that he was going to teach us during the term. A key was Ansel Adams' "Zone System" for previsualizing the print values (blackness in the final print) in a photograph and how they derive from the light intensities in the scene. In support of this skill we had to learn the use of exposure meters to measure light intensities and the use of exposure time and development time to control the black level and the contrast in the image. This is in turn supported by even lower level skills such as loading film, developing and printing, and mixing chemicals. One must learn to ritualize the process of developing sensitive material so that one gets consistent results over many years of work. The first laboratory session was devoted to finding out that developer feels slippery and that fixer smells awful.
But what about creative composition? In order to be creative one must first gain control of the medium. One can not even begin to think about organizing a great photograph without having the skills to make it happen. In engineering, as in other creative arts, we must learn to do analysis to support our efforts in synthesis. One cannot build a beautiful and functional bridge without a knowledge of steel and dirt and considerable mathematical technique for using this knowledge to compute the properties of structures. Similarly, one cannot build a beautiful computer system without a deep understanding of how to "previsualize" the processes generated by the procedures one writes.
Some photographers choose to use black-and-white 8x10 plates while others choose 35mm slides. Each has its advantages and disadvantages. Like photography, programming requires a choice of medium. Lisp is the medium of choice for people who enjoy free style and flexibility. Lisp was initially conceived as a theoretical vehicle for recursion theory and for symbolic algebra. It has developed into a uniquely powerful and flexible family of software development tools, providing wrap-around support for using a vast library of canned parts, produced by members of the user community. In Lisp, procedures are first-class data, to be passed as arguments, returned as values, and stored in data structures. This flexibility is valuable, but most importantly, it provides mechanisms for formalizing, naming, and saving the idioms — the common patterns of usage that are essential to engineering design. In addition, Lisp programs can easily manipulate the representations of Lisp programs — a feature that has encouraged the development of a vast structure of program synthesis and analysis tools, such as cross-referencers.
The Little LISPer is a unique approach to developing the skills underlying creative programming in Lisp. It painlessly packages, with considerable wit, much of the drill and practice that is necessary to learn the skills of constructing recursive processes and manipulating recursive data-structures. For the student of Lisp programming, The Little LISPer can perform the same service that Hanon's finger exercises or Czerny's piano studies perform for the student of piano.
— Gerald J. Sussman, Cambridge, Massachusetts
Preface
Programs accept data and produce data. Designing a program requires a thorough understanding of data; a good program reflects the shape of the data it deals with. Most collections of data, and hence most programs, are recursive. Recursion is the act of defining an object or solving a problem in terms of itself.
The goal of this book is to teach the reader to think recursively. Our first task is to decide which language to use to communicate this concept. There are three obvious choices: a natural language, such as English; formal mathematics; or a programming language. Natural languages are ambiguous, imprecise, and sometimes awkwardly verbose. These are all virtues for general communication, but something of a drawback for communicating concisely as precise a concept as recursion. The language of mathematics is the opposite of natural language: it can express powerful formal ideas with only a few symbols. Unfortunately, the language of mathematics is often cryptic and barely accessible without special training. The marriage of technology and mathematics presents us with a third, almost ideal choice: a programming language. We believe that programming languages are the best way to convey the concept of recursion. They share with mathematics the ability to give a formal meaning to a set of symbols. But unlike mathematics, programming languages can be directly experienced — you can take the programs in this book, observe their behavior, modify them, and experience the effect of these modifications.
Perhaps the best programming language for teaching recursion is Scheme. Scheme is inherently symbolic — the programmer does not have to think about the relationship between the symbols of his own language and the representations in the computer. Recursion is Scheme's natural computational mechanism; the primary programming activity is the creation of (potentially) recursive definitions. Scheme implementations are predominantly interactive — the programmer can immediately participate in and observe the behavior of his programs. And, perhaps most importantly for our lessons at the end of this book, there is a direct correspondence between the structure of Scheme programs and the data those programs manipulate.
Although Scheme can be described quite formally, understanding Scheme does not require a particularly mathematical inclination.
In fact, The Little Schemer is based on lecture notes from a two-week "quickie" introduction to Scheme for students with no previous programming experience and an admitted dislike for anything mathematical.
Many of these students were preparing for careers in public affairs.
It it our belief that writing programs recursively in Scheme is essentially simple pattern recognition. Since our only concern is recursive programming, our treatment is limited to the whys and wherefores of just a few Scheme features: car, cdr, cons, eq?, null?, zero?, add1, sub1, number?, and, or, quote, lambda, define, and cond.
Indeed, our language is an idealized Scheme.
The Little Schemer and The Seasoned Schemer will not introduce you to the practical world of programming, but a mastery of the concepts in these books provides a start toward understanding the nature of computation.