Abstract

this paper we explore an approach which enables all of the problems listed above to be solved at a single stroke: use Lisp as the source language for the numeric and graphical code! This is not a new idea --- it was tried at MIT and UCB in the 1970's. While these experiments were modestly successful, the particular systems are obsolete. Fortunately, some of those ideas used in Maclisp [37], NIL [38] and Franz Lisp [20] were incorporated in the subsequent standardization of Common Lisp (CL) [35]. In this new setting it is appropriate to re-examine the theoretical and practical implications of writing numeric code in Lisp. The popular conceptions of Lisp's inefficiency for numerics have been based on rumor, supposition, and experience with early and (in fact) inefficient implementations. It is certainly possible to continue to write inefficient programs: As one example of the results of de-emphasizing numerics in the design, consider the situation of the basic arithmetic operators. The definitions of these functions require that they are generic, (e.g. "+" must be able to add any combination of several precisions of floats, arbitrary-precision integers, rational numbers, and complexes), The very simple way of implementing this arithmetic -- by subroutine calls -- is also very inefficient. Even with appropriate declarations to enable more specific treatment of numeric types, compilers are free to ignore declarations and such implementations naturally do not accommodate the needs of intensive number-crunching. (See the appendix for further discussion of declarations). Be this as it may, the situation with respect to Lisp has changed for the better in recent years. With the advent of ANSI standard Common Lisp, several active vendors of implementations and one active universi...

Citations