Report on the 1980 LiSP Conference Stanford University. August 25-27, 1980

The 1980 LISP Conference is, to my knowledge, the second conference ever held oit the subject of the LISP language. The first was in Mexico City in 1964. This chronological gap would seem to indicate a lack of interest in LISP, but LISP is in fact a vigorous and thriving language. For most of its history LISP has been used primarily in Artificial Intelligence applications. 1 More recently, however, it has been used as a systems programming language to implement such systems as general text editors (see the abstract of Greenberg's paper (3) below). While LISP has been known primarily for non-numeric, symbolic processing, optimizing compilers have been written that compete with FORTRAN in efficiency. 2 John McCarthy, inventor of LISP, notes that LISP is the second or third oldest surviving programming language (depending on whether or not you count APT), and suggests that "LISP has survived for 21 years because it is an approximate local optimum in the space of programming languages." This has not kept people from trying to improve on LISP, however, by either revision or extension. One topic debated dunng the conference was whether it would be a good thing to construct a version of LISP frith strong data typing. 3 Arguments raised in tiavor of this include increased error-checking, reliability, mad ease of verification; arguments against include the flexibility of typelessness and faster program production and turnaround in experimental, interactive situations. Of thirty-one papers, at least five (7, 8, 10, 18, 22) were concerned with data types, modes, and abstraction. Multiprocessing was another topic of great interest. Over one-fourth of the papers presented (3, 4, 5, i2, 15, 24, 25, 26) dealt with multiprocessing, parallelism, and cooperating processes. A third area of interest, not surprisingly, was efficiency. Like most interpreter-based languages, LISP has suffered from a mythical and undeserved reputation for slowness. APL suffered from a similar reputation, but recently clever interpretation algorithms (particularly in the proprietary commercial time-sharing implementations) have made it incredibly fast. LISP, too, can be fast when interpreted or compiled correctly; better techniques for heap storage management can also help. were concerned directly with efficiency or compilation techniques, and others were so concerned indirectly. There was a panel session on possible futures for LISP, which became a lively audience-participation discussion. There was not a great deal of agreement on any issue, but then again no issue suffered from lack of interest. …