The code that implements the algorithm for traversing program structure (code walking) is completely portable. However, XREF must make some assumptions about the implementation in which it runs, and the organization of the programs that it analyzes. The remainder of this paper will address some of these assumptions.



3    The Superset Problem

The first attempt at porting XREF to other environments revealed that a major assumption would not be met. The assumption is that implementers would heed the advice on page 58 of CLtL:

Implementors are encouraged to implement the macros defined in this manual, as far as possible, in such a way that the expansion will not contain any implementation- dependent special forms, nor contain as forms data objects that are not considered to be forms in COMMON LISP. The purpose of this restriction is to ensure that the expansion can be processed by a program-analyzing program in an implementation-independent manner. There is no problem with a macro expansion containing calls to implementation-dependent functions. This restriction is not a requirement of COMMON LISP...

Some implementations of COMMON LISP based on ZETALISP [4] found this restriction inexpedient.⁵ So when XREF encountered macros (e.g., defstruct) that expanded into code that included implementation-dependent special forms [e.g., defprop) it did not understand the syntax of the special forms and was therefore unable to analyze portable programs. In order to run in these extended implementations, XREF needed additional code to handle ZETALISP special forms. Furthermore, the superset implementations treated some of the COMMON LISP macros, such as and and cond as special forms. CLtL allows this as long me macro definitions are also supplied. One superset implementation did not supply alternate macro definitions, and the other did provide alternates but macroexpand-1 failed to apply them. Thus XREF could not rely on the presumably portable form-processing algorithm recommended on page 57 of CLtL, and had to be modified to account for the handling of special forms in superset implementations.⁶

A second portability problem relating to the superset issue concerns the package in which COMMON LISP symbols reside. CLtL states that the LISP package must contain all of the symbols defined in the book. However, it is not clear which other symbols may be found there (exported). Thus when XREF was brought to the superset implementations, name clashes occurred between functions defined by the program and functions supplied in the extended LISPs. For example, in one ZETALISP implementation, the symbol string-search naming the ZETALISP function is automatically included in any package that uses the LISP package. XREF defined its own string-search function, since it is not included in COMMON LISP, and


*****************
5    This was the case for the two implementations that the author checked: Version 6 of the Symbolics Lisp Machine [5] and Version 2 of the Texas Instruments Explorer [6] (both names are trademarks of the respective com ames .

6    XREF has been successfully ported to run on the Texas Instruments Explorer, but it must ignore those special forms that it does not understand. This introduces errors of omission (e.g., a. function call or variable reference may not be recorded), so the validity of the cross reference reports cannot be guaranteed.