Peter Siebel - Practical Common Lisp

pass ... (TEST-MATH TEST-ARITHMETIC TEST-*): (= (* 2 2) 4)

pass ... (TEST-MATH TEST-ARITHMETIC TEST-*): (= (* 3 5) 15)

T

You could keep going, adding more features to this test framework. But as a framework for writing tests with a minimum of busywork and easily running them from the REPL, this is a reasonable start. Here's the complete code, all 26 lines of it:

(defvar *test-name* nil)

(defmacro deftest (name parameters &body body)

"Define a test function. Within a test function we can call

other test functions or use 'check' to run individual test

cases."

`(defun ,name ,parameters

(let ((*test-name* (append *test-name* (list ',name))))

,@body)))

(defmacro check (&body forms)

"Run each expression in 'forms' as a test case."

`(combine-results

,@(loop for f in forms collect `(report-result ,f ',f))))

(defmacro combine-results (&body forms)

"Combine the results (as booleans) of evaluating 'forms' in order."

(with-gensyms (result)

`(let ((,result t))

,@(loop for f in forms collect `(unless ,f (setf ,result nil)))

,result)))

(defun report-result (result form)

"Report the results of a single test case. Called by 'check'."

(format t "~:[FAIL~;pass~] ... ~a: ~a~%" result *test-name* form)

result)

It's worth reviewing how you got here because it's illustrative of how programming in Lisp often goes.

You started by defining a simple version of your problem—how to evaluate a bunch of boolean expressions and find out if they all returned true. Just AND ing them together worked and was syntactically clean but revealed the need for better result reporting. So you wrote some really simpleminded code, chock-full of duplication and error-prone idioms that reported the results the way you wanted.

The next step was to see if you could refactor the second version into something as clean as the former. You started with a standard refactoring technique of extracting some code into a function, report-result. Unfortunately, you could see that using report-resultwas going to be tedious and error-prone since you had to pass the test expression twice, once for the value and once as quoted data. So you wrote the checkmacro to automate the details of calling report-resultcorrectly.

While writing check, you realized as long as you were generating code, you could make a single call to checkto generate multiple calls to report-result, getting you back to a version of test-+about as concise as the original AND version.

At that point you had the checkAPI nailed down, which allowed you to start mucking with how it worked on the inside. The next task was to fix checkso the code it generated would return a boolean indicating whether all the test cases had passed. Rather than immediately hacking away at check, you paused to indulge in a little language design by fantasy. What if—you fantasized—there was already a non-short-circuiting AND construct. Then fixing checkwould be trivial. Returning from fantasyland you realized there was no such construct but that you could write one in a few lines. After writing combine-results, the fix to checkwas indeed trivial.

At that point all that was left was to make a few more improvements to the way you reported test results. Once you started making changes to the test functions, you realized those functions represented a special category of function that deserved its own abstraction. So you wrote deftestto abstract the pattern of code that turns a regular function into a test function.

With deftestproviding an abstraction barrier between the test definitions and the underlying machinery, you were able to enhance the result reporting without touching the test functions.

Now, with the basics of functions, variables, and macros mastered, and a little practical experience using them, you're ready to start exploring Common Lisp's rich standard library of functions and data types.

While functions, variables, macros, and 25 special operators provide the basic building blocks of the language itself, the building blocks of your programs will be the data structures you use. As Fred Brooks observed in The Mythical Man-Month , "Representation is the essence of programming." [107] Fred Brooks, The Mythical Man-Month , 20th Anniversary Edition (Boston: Addison-Wesley, 1995), p. 103. Emphasis in original.

Common Lisp provides built-in support for most of the data types typically found in modern languages: numbers (integer, floating point, and complex), characters, strings, arrays (including multidimensional arrays), lists, hash tables, input and output streams, and an abstraction for portably representing filenames. Functions are also a first-class data type in Lisp—they can be stored in variables, passed as arguments, returned as return values, and created at runtime.

And these built-in types are just the beginning. They're defined in the language standard so programmers can count on them being available and because they tend to be easier to implement efficiently when tightly integrated with the rest of the implementation. But, as you'll see in later chapters, Common Lisp also provides several ways for you to define new data types, define operations on them, and integrate them with the built-in data types.

For now, however, you can start with the built-in data types. Because Lisp is a high-level language, the details of exactly how different data types are implemented are largely hidden. From your point of view as a user of the language, the built-in data types are defined by the functions that operate on them. So to learn a data type, you just have to learn about the functions you can use with it. Additionally, most of the built-in data types have a special syntax that the Lisp reader understands and that the Lisp printer uses. That's why, for instance, you can write strings as "foo"; numbers as 123, 1/23, and 1.23; and lists as (a b c). I'll describe the syntax for different kinds of objects when I describe the functions for manipulating them.

In this chapter, I'll cover the built-in "scalar" data types: numbers, characters, and strings. Technically, strings aren't true scalars—a string is a sequence of characters, and you can access individual characters and manipulate strings with a function that operates on sequences. But I'll discuss strings here because most of the string-specific functions manipulate them as single values and also because of the close relation between several of the string functions and their character counterparts.

Math, as Barbie says, is hard. [108] Mattel's Teen Talk Barbie Common Lisp can't make the math part any easier, but it does tend to get in the way a lot less than other programming languages. That's not surprising given its mathematical heritage. Lisp was originally designed by a mathematician as a tool for studying mathematical functions. And one of the main projects of the MAC project at MIT was the Macsyma symbolic algebra system, written in Maclisp, one of Common Lisp's immediate predecessors. Additionally, Lisp has been used as a teaching language at places such as MIT where even the computer science professors cringe at the thought of telling their students that 10/4 = 2 , leading to Lisp's support for exact ratios. And at various times Lisp has been called upon to compete with FORTRAN in the high-performance numeric computing arena.