"This section of the web is devoted to teach the art of programming in Lisp."
As the size of software systems being created and -- more importantly -- maintained increases, it becomes more important than ever to write clean, robust, modular programs. Hoare's ``Emperor's New Clothes'' is a spectre that haunts anyone engaged in the task of creating complex software systems today. And in a future that promises automatic generation and verification of programs, programming constructs and techniques that have simple, rigorous semantics will be of primary importance to help these intelligent tools function.
The appearance of iterators in an object-oriented language appears to be inversely related to the power of the language's intrinsic control structures. Iterator classes are used for the sole purpose of enumerating the elements of an abstract collection class without revealing its implementation. We find that the availability of higher-order functions and function closures eliminates the need for these ad hoc iterator classes, in addition to providing the other benefits of "mostly functional programming".
This is a straightforward implementation of a data structure called a heap. It's mostly a Lisp version of the heap implementation Mark Allen Weiss gives in [Wei97]. Doctor Weiss's implementation is for C, not Lisp, so my mostly direct translation probably is not as Lispy as it could be. Then again, I don't see much that's particularly Lispy about heaps in the first place
This is a list of "pitfalls": little traps that can catch even
experienced programmers. They often involve somewhat counterintuitive aspects of Common Lisp that tend to be revealed only by a careful reading of CLtL (or of the ANSI standard). However, pitfalls do not necessarily represent defects in the language.
lisp-unit is a Common Lisp library that supports unit testing
In 1981 the emerging Common Lisp community turned to Scheme for some of its motivation and inspiration [Steele 1984]. Adopting lexical scooping proved one of the most important decisions the Common Lisp group ever made.
One aspect of Scheme that was not adopted, however, was a single namespace for functions and values, along with uniform evaluation rules for expressions in function and argument positions within the language. At the 1986 ACM Conference on Lisp and Functional Programming, members of a part of the European Lisp community (called the EuLisp group) involved in the design of a Lisp dialect suggested that Common Lisp should have adopted this paradigm and that it might still be appropriate to do so.
Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
John McCarthy, Massachusetts Institute of Technology, Cambridge, Mass. 1
April 1960