Some Useful Lisp Algorithms: Part 2

    •  Richard C. Waters, "Some Useful Lisp Algorithms: Part 2", Tech. Rep. TR93-17, Mitsubishi Electric Research Laboratories, Cambridge, MA, August 1993.
      BibTeX TR93-17 PDF
      • @techreport{MERL_TR93-17,
      • author = {Richard C. Waters},
      • title = {Some Useful Lisp Algorithms: Part 2},
      • institution = {MERL - Mitsubishi Electric Research Laboratories},
      • address = {Cambridge, MA 02139},
      • number = {TR93-17},
      • month = aug,
      • year = 1993,
      • url = {}
      • }
  • MERL Contact:

This technical report gathers together three papers that were written during 1992 and 1993 and submitted for publication in ACM Lisp Pointers. Chapter 1 "Using the New Common Lisp Pretty Printer" explains how the pretty printing facilities that have been adopted as part of the forthcoming Common Lisp standard can be used to gain detailed control over the printing of lists. As an example, it shows how the pretty printer can be used to print a subset of Lisp as Pascal. Chapter 2 "Macroexpand-All: An Example of a Simple Lisp Code Walker" presents a function MACROEXPAND-ALL for expanding all the macro calls in a Lisp expression. This is useful when debugging macros and can be helpful as a subroutine when writing complex macros. In addition, the chapter serves as an introduction to code walkers---the general class of programs of which MACROEXPAND-ALL is an example. Code walkers are important because they are a vital part of the foundation of many Lisp programming tools and macro packages. Chapter 3 "To NReverse When Consing a List or By Pointer Manipulation, To Avoid It; That Is the Question" discusses a question that Lisp programmers have argued about for decades. When creating an ordered list of elements it is often convenient to push the items onto the list one at a time and then call NREVERSE to put resulting list in the correct order. By writing more complex code, you can enter the elements in the list in the correct order in the first place. It seems that this latter approach should be faster and better since it avoids calling NREVERSE, but is it?