Basically, this paper is a polemic about LISP arithmetic. It starts with an overview of why one might want to do floating point arithmetic in LISP: there are packages that do a combination of symbolic and numerical mathematics, and techniques that glue pieces of FORTRAN object code into LISP programs do not work very well. Then it looks at the advantages and disadvantages of Common Lisp for numerical programming. On the disadvantage side, LISP’s very late binding and automatic storage management can make it difficult to generate object code that is competitive with FORTRAN. LISP supports a large set of numeric types, and does not require that the types of variables be declared before use. Hence, it is possible that an operand to an addition might be a double-precision float one time, but a multiprecision integer the next, forcing operations to be interpreted rather than compiled in-line. Procedures can be called with varying numbers and types of arguments. To aid in garbage collection, values are usually “boxed,” stored in a separate area of memory and referred to indirectly through pointers. The authors describe methods by which each of these impediments to efficient compilation may be addressed.

On the positive side, LISP can be used as a much higher-level language than FORTRAN, and a polynomial evaluation, for example, can be written as a LISP macro that, at compile time, selects one of a variety of different algorithms based on the types and values of the argument and coefficients. Loops can be expressed in various high-level ways that similarly allow optimizations not possible in lower-level code. LISP has much more flexible storage management than FORTRAN, permitting far more effective data sharing than FORTRAN COMMON allows. Storage allocation to make the most effective use of hardware caches is also possible, again because LISP allows a higher-level description of algorithms.

The authors look at the object code generated by some widely used LISP compilers for a few common numerical tasks such as clearing an array and matrix multiplication. While not as good as the code from an optimizing FORTRAN compiler, LISP code is better than unoptimized FORTRAN and is usually within a small integer factor of the best FORTRAN. The authors suggest, waving their hands somewhat, that improving the quality of the LISP code would not be hard.

They finish by describing a prototype FORTRAN-to-LISP translator that turns FORTRAN code into equivalent LISP, making the LISP as amenable as possible to efficient calculation. The hand-waving gets intense in this part (“We expect to continue to refine the tool”), but it is clear that even the prototype is good enough to translate chunks of FORTRAN into LISP that is usable directly or with modest tweaking.

Programmers familiar with both LISP and numerical programming (an admittedly small group) have known for decades that it is possible to write LISP numeric code that runs adequately fast. As the size and complexity of numerical packages continue to grow, numerical programmers steeped in FORTRAN should consider that a package that runs a little slower than a FORTRAN version is a lot better than one that does not run at all, and LISP is a more productive programming language than FORTRAN will ever be.