Uniquely characteristic of Lisp is its evaluation mechanism: eval. Although this book talks relentlessly about evaluation, we haven't said a word yet about the problem of making evaluation available to programmers. Evaluation poses a number of problems with respect to specification, integrity, and linguistics. Some people are thinking of all these problems when they say concisely, “eval is evil” Catching its genius in a useful form is the first step toward programming reflection, a topic this chapter also covers.

For 271 pages now, we've been presenting various interpreters detailing the core of the evaluation mechanism. For most of them, making the evaluation mechanism accessible to programmers is trivial, a task requiring very little code. That's what implementers have been doing for ages. The existence of such a mechanism [see p. 2] was surely one of the goals in creating Lisp. From the very beginning of the sixties, in fact, making the eval function explicit showed up in the writings of the founders, such as [McC60, MAE+62].

Explicit evaluation is fundamental, supporting as it does so many effects, notably, a powerful system of macros, immersion of the programming environment within the language, and pronounced reflection. Of course, explicit evaluation also has some defects such as macros, a programming environment right inside the language, and invasive reflection. Like a magic djinn, explicit evaluation can be both useful and dangerous.