perm filename ARPA.PRO[COM,LSP] blob sn#686862 filedate 1982-11-08 generic text, type C, neo UTF8
C00001 00001
C00002 00002	Ron, I gave the following  note to McCarthy to forward to
C00016 ENDMK
Ron, I gave the following  note to McCarthy to forward to
Bob and you, but perhaps he did not send it. I have just returned
from DEC in New Hampshire where Martin Griss and I (among others)
participated in a review of the Common Lisp project for the Vax
being done by CMU. I am in the process of putting together my
evaluation of that project right now. While there I leared that
Steele and Fahlman intend to get the White pages (the manual)
to a printer (Digital Press) in January or February. I will be
writing certain parts of it between now and then.  That implementation
will be released this winter by DEC.

The dedicated projects are: S-1, Symbolics, CMU (Spice and Vax),
Rutgers (DEC-20). LMI plans, I believe, to keep up, but they
lack manpower. PSL would like to become dedicated but they do
not have any funding for Lisp development.

The library and the Blue pages (described below) and the next
steps to take. 


Common Lisp is the combined effort of 8 different Lisp implementation
groups* aimed at producing a common dialect of Lisp while allowing each
group to exploit its own hardware. Common Lisp is a set of documents, a
language design, and a common body of code.

[* These group are: Spice Lisp at CMU, DEC Common Lisp on Vax at CMU, DEC
Common Lisp on DEC-20 at Rutgers, S-1 Lisp at LLNL, Symbolics Common Lisp,
LMI Common Lisp, Portable Standard Lisp at Utah, and Vax NIL.]

The Common Lisp documentation is divided into four parts, known as the
white pages, the yellow pages, the red pages, and the blue pages.

The white pages is a language specification rather than an implementation
specification.  It defines a set of standard language concepts and
constructs that may be used for communication of data structures and
algorithms in the Common Lisp dialect.  This is sometimes referred to as
the ``core Common Lisp language'', because it contains conceptually
necessary or important features.  It is not necessarily implementationally
minimal.  While some features could be defined in terms of others by
writing Lisp code (and indeed may be implemented that way), it was felt
that these features should be conceptually primitive so that there might
be agreement among all users as to their usage.  (For example, bignums and
rational numbers could be implemented as Lisp code given operations on
fixnums.  However, it is important to the conceptual integrity of the
language that they be regarded by the user as primitive, and they are
useful enough to warrant a standard definition.)

The yellow pages is a program library document, containing documentation
for assorted and relatively independent packages of code.  While the white
pages are to be relatively stable, the yellow pages are extensible; new
programs of sufficient usefulness and quality will routinely be added from
time to time.  The primary advantage of the division into white and yellow
pages is this relative stability; a package written solely in the
white-pages language should not break if changes are made to the
yellow-pages library.

The red pages is implementation-dependent documentation; there will be one
set for each implementation.  Here are specified such
implementation-dependent parameters as word size, maximum array size,
sizes of floating-point exponents and fractions, and so on, as well as
implementation-dependent functions such as input/output primitives.

The blue pages constitutes an implementation guide in the spirit of the
Interlisp virtual machine specification.  It specifies a subset of the
white pages that an implementor must construct, and indicates a quantity
of Lisp code written in that subset that implements the remainder of the
white pages.  In principle there could be more than one set of blue pages,
each with a companion file of Lisp code.  (For example, one might assume
IF to be primitive and define COND as a macro in terms of IF, while
another might do it the other way around.)

At present the white pages portion of Common Lisp is nearly complete, that
document being edited by Guy Steele Jr. at CMU. Since Guy Steele is
taking a leave-of-absence from CMU to work at Tartan Labs, and since Scott
Fahlman, the head of the Spice Lisp project and a major contributor to
Common Lisp, wants to return to his AI research, the administrative
control of the Common Lisp effort is in question with several important
parts left undone. Stanford proposes to complete those parts.

In particular we propose to do three things.  We will complete the white
pages: though Guy Steele will be able to work several hours a week on that
task while at Tartan Labs, it may prove impractical for him to spend all
the time needed for the job. We will help him finish the writing and
editting, arrange and direct the Common Lisp Group meetings, and perform
the administrative work necessary to complete the language specification
and documentation.

We will produce the first version of the yellow pages. This task consists
of gathering proposed packages, validating the documentation, insuring the
portability, and doing some testing of the code before it is included in
the yellow pages. All code will be uniformly housed at Stanford with
access to all ARPA contractors.

Finally, and most importantly, we will produce the first version of the
blue pages. This requires producing a detailed specification of the subset
of the white pages that must be written, expanding on the white pages
description where necessary. We will also write, test, and document an
implementation of Common Lisp in that subset and make that code available
to anyone wanting to implement a Common Lisp. Thus, for any group to
implement a Common Lisp, all that will need to be done is to write the
specified subset language in whatever other language their hardware
supports and to then take a copy of the Lisp code we will have produced
which will complete the implementation of the white pages language.

This last part assumes that Eric Benson, one of the main people behind the
Utah Portable Standard Lisp project, can be hired. He is uniquely
qualified to perform this task, and he has expressed strong interest in
performing the work. He is currently living in the Bay Area, consulting to
Hewlett-Packard Laboratories.

I should note that the blue pages does not include a portable compiler,
though this would be of extraordinary importance to the usefulness and
survival of Common Lisp. There are several possible ways of approaching
this problem. One way is to adapt the S-1 Lisp compiler. The S-1 compier
is an optimizing compiler based on techniques used in the Bliss-11
compiler; it is being written by Guy Steele, Dick Gabriel, and Rod Brooks.
Although largely table-driven, it is not currently divided well into the
machine-independent and machine-dependent parts. Of 220 pages of code, 60
are machine-dependent; a significant proportion of the machine-dependent
part is table-driven (the register allocator, for example), and the rest
is code generators. Some knowledge of the S-1 architecture is built into
other parts of the compiler in a non-systematic way.  Lawrence Livermore
National Laboratory has placed the S-1 compiler (and all of the Common
Lisp implemenation code developed there) in the public domain. LLNL
neither has the resources to undertake such a compiler development project
nor is it within their mandate to do so.

Another possible source of a portable compiler is the PSL compiler.  This
compiler, though not as highly optimizing as the S-1 compiler, is,
nevertheless, addressed directly to the portability question in Lisp
compilers.  The PSL compiler would need to be retargetted to compile
Common Lisp, but this requires it to compile only about 30 constructs
specially - the rest can be defined as macros on those (this is also the
approach of the S-1 compiler).

Finally, one of the other compilers from the Common Lisp group could be
used, though this possibility is not promising at the moment. Perhaps a
large manufacturer (DEC, for example) could be persuaded to do this work.
Such a company could find this to their advantage if they perceived a
committment to Common Lisp in the ARPA community that could translate into
a market for them.

Stanford would be willing to perform this work; but the cost would be
fairly high, requiring several additional students. The proposed budget,
included below, only covers travel, computer use, and salary for Benson in
order to total less than $100,000 per year.

This completes the informal description of the Common Lisp work that
Stanford proposed to undertake for ARPA. The proposed budget is attached
as a supplement.