---

A Note on S-expressions–Forms–Types

The development of the package system is related to the change of focus from S-expressions to forms. The index of CLtL-2 contains no entry for S-expressions or symbolic expressions, but the entry for forms contains 14 subentries and points to a total of 39 different pages.

The change in focus from S-expressions to forms is bound up with the devel- opment of a mature typing system, since Common Lisp has typed objects rather than typed expressions.

S-expressions

S-expressions are syntactic units, sequences of characters that form the written version of Lisp programs and data structures.

We used to say that the Lisp language consisted of S-expressions, the major action of Lisp was the evaluation of S-expressions, and the read-eval-print loop consisted of reading an S-expression, evaluating it, and then printing the value as an S-expression.

Forms

A form, on the other hand, is a Common Lisp object that can be evaluated, and the major action of Common Lisp is the evaluation of such forms, or objects.

The Common Lisp read-eval-print loop really has five steps:

1. reading an S-expression,
2. creating the object the S-expression denotes,
3. evaluating the object,
4. choosing a printed representation of the value, and
5. printing that representation.

Types

Common Lisp has an extensive set of types, each with a predicate to rec- ognize objects of that type and a collection of operations defined for it, all organized into a type hierarchy.

Types covered include:

• numbers (integers, floating-point numbers, and ratios),
• characters,
• strings,
• symbols,
• packages,
• lists,
• conses,
• functions,
• hash tables, and
• single dimensional arrays

Common Lisp is an object-oriented language similar to the way that CLU is object-oriented, as opposed to the modern meaning of that phrase in object-oriented programming. Common Lisp is object-oriented in the sense that:

• variables have objects as their values, and
• two variables can be bound to the same object;
• composite objects have objects as their parts;
• objects, rather than expressions, have values and types

To see the significance of Common Lisp’s typing of objects, compare an untyped language such as Fortran with a strongly typed language such as Pascal with Common Lisp. In Fortran, one may store a value of one type into a variable, and then pass that variable by reference to a procedure that operates on it as if it were another type. In Pascal, the compiler would catch this as an error because the variable would be declared as one type, whereas the formal parameter would be declared as another type. In Common Lisp, this would be caught as an error during execution because the operator would complain that the object it was given to operate on was of the wrong type.

Common Lisp has a macro check-type that can be used to make sure the objects passed to a function are of the correct type. One may choose never to use check-type, but one then runs the risk of a built-in function, called many levels deep in user-defined functions, complaining that some object is of the wrong type. It then can be very hard to find which function actually made the mistake.

Evaluation

Unlike other programming languages, Lisp does not operate on a series of imperative statements—“do this, then do this, and so on,” but rather on ex- pressions, called symbolic expressions or S-expressions, which Lisp evaluates.

More accurately, a session with Common Lisp involves an interaction with a Lisp listener, during which the following five steps are repeated until you decide to stop:

1. You type an S-expression to the Lisp listener.
2. The Lisp listener interprets your S-expression as the printed representation of a Common Lisp object.
3. That object is evaluated. Its value is also a Common Lisp object.
4. The Lisp listener chooses a printed representation for the value object.
5. That printed representation is printed for you to read.

Common Lisp is object-oriented in the sense that objects, rather than expres- sions, are evaluated, and unlike many other programming languages, objects, rather than expressions, have types.