Like most everything, LISP is subject to improvement. The various versions of LISP have accumulated many barnacles with time, and these would have to be scraped off before a definitive standardizable language could be achieved - a worthwhile but long term goal. Meanwhile here are a few directions for improvement. Some are purely operational and others have more conceptual content.
Designers of programming languages often propose omitting from the definition of the language facilities that can be defined within the language on the grounds that the user can do it for himself. The result is often that users cannot use each other's programs, because each installation and user performs various common tasks in different ways. In so far as programmers use local libraries without rewriting the functions, they are using different languages if they use different local libraries. Compatibility between users of LISP would be much enhanced if there were more standard functions.
A notation for representing symbolic information can be optimized from three points of view: One can try to make it easy to write. One can try to make it easy and pleasant to read. One can make easy to manipulate with computer programs. Unfortunately, these desiderata are almost always grossly incompatible. LISP owes most of its success to optimizing the third. LISP lists and S-expressions in which the car of an item identifies its kind have proved most suitable as data for programming. When the amount of input and output is small, users are inclined to accept the inconvenience of entering the input and seeing the output as lists or S-expressions. Otherwise they write read and print programs of varying elaborateness. Input and output programs are often a large part of the work and a major source of bugs. Moreover, input programs often must detect and report errors in the syntax of input.
LISP would be much improved by standard facilities for syntax directed input and output. Some years ago Lynn Quam implemented a system that used the same syntax description for both input and output, but this was rather constraining. Probably one wants different syntaxes for input and output, and input syntaxes should specify ways of complaining about errors. The idea is to provide standard facilities for a programmer to describe correspondences between data in an external medium and S-expressions, e.g. he should be able to say something like
,
,
although I hold no brief for this particular notation.
It isn't clear whether this would be a feature to be added to LISP or a new language. However, it seems likely that both the functional form of computation that LISP has now and syntax directed features are wanted in one language.
