Rutgers lisp development project

[HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)]

It now appears that we are going to do an implementation of Common Lisp
for the DEC-20.  This project is being funded by DEC.

		Why are we doing this project at all?

This project is being done because a number of our researchers are going
to want to be able to move their programs to other systems than the
DEC-20.  We are proposing to get personal machines over the next few
years.  Sri has already run into problem in trying to give AIMDS to
someone that only has a VAX.  Thus we think our users are going to want
to move to a dialect that is widely portable.

Also, newer dialects have some useful new features.  Although these
features can be put into Elisp, doing so will introduce
incompatibilities with old programs.  R/UCI Lisp already has too many
inconsistencies introduced by its long history.  It is probably better
to start with a dialect that has been designed in a coherent fashion.

			Why Common Lisp?

There are only three dialects of Lisp that are in wide use within the
U.S. on a variety of systems:  Interlisp, meta-Maclisp, and Standard
Lisp.  (By meta-Maclisp I mean a family of dialects that are all
related to Maclisp and generally share ideas.)  Of these, Standard Lisp
has a reputation of not being as "rich" a language, and in fact is not
taken seriously by most sites.  This is not entirely fair, but there is
probably nothing we can do about that fact at this stage. So we are left
with Interlisp and meta-Maclisp.  A number of implementors from the
Maclisp family have gotten together to define a common dialect that
combines the best features of their various dialects, while still being
reasonable in size.  A manual is being produced for it, and once
finished will remain reasonably stable.  (Can you believe it?
Documentation before coding!)  This dialect is now called Common Lisp.
The advantages of Common Lisp over Interlisp are:

  - outside of BBN and Xerox, the Lisp development efforts now going on
	all seem to be in the Maclisp family, and now are being
	redirected towards Common Lisp.  These efforts include
	CMU, the Lisp Machine companies (Symbolics, LMI), LRL and MIT.

  - Interlisp has some features, particularly the spaghetti stack,
	that make it impossible to implement as efficiently and cleanly
	as Common Lisp.  (Note that it is possible to get as good
	effiency out of compiled code if you do not use these features,
	and if you use special techniques when compiling.  However that
	doesn't help the interpreter, and is not as clean.)

  - Because of these complexities in Interlisp, implementation is a
	large and complex job.  ARPA funded a fairly large effort at
	ISI, and even that seems to be marginal.  This comment is based
	on the report on the ISI project produced by Larry Masinter,
	<lisp>interlisp-vax-rpt.txt.  Our only hope would be to take
	the ISI implementation and attempt to transport it to the 20.
	I am concerned that the result of this would be extremely slow.
	I am also concerned that we might turn out not to have the
	resources necessary to do it a good job.

  - There seems to be a general feeling that Common Lisp will have a
	number of attractive features as a language.  (Notice that I am
	not talking about user facilities, which will no doubt take some
	time before they reach the level of Interlisp.)  Even people
	within Arpa are starting to talk about it as the language of the
	future.  I am not personally convinced that it is seriously
	superior to Interlisp, but it is as good (again, at the language
	level), and the general Maclisp community seems to have a number
	of ideas that are significantly in advance of what is likely to
	show up in Interlisp with the current support available for it.

There are two serious disadvantages of Common Lisp:

  - It does not exist yet.  As of this week, there now seem to be
	sufficient resources committed to it that we can be sure it will
	be implemented.  The following projects are now committed, at a
	level sufficient for success:  VAX (CMU), DEC-20 (Rutgers), PERQ
	and other related machines (CMU), Lisp Machine (Symbolics), S-1
	(LRL).  I believe this is sufficient to give the language a
	"critical mass".

  - It does not have user facilities defined for it.  CMU is heavily
	committed to the Spice (PERQ) implementation, and will produce
	the appropriate tools.  They appear to be funded sufficiently
	that this will happen.

		 Why is DEC funding it, and what will be
		 	our relationship with them?

LCG (the group within DEC that is responsible for the DEC-20) is
interested in increasing the software that will support the full 30-bit
address space possible in the DEC-20 architecture.  (Our current
processor will only use 23 bits of this, but this is still much better
than what was supported by the old software, which is 18 bits.)  They
are proceeding at a reasonable rate with the software that is supported
by DEC.  However they recognize that many important languages were
developed outside of DEC, and that it will not be practical for them
to develop large-address-space implementations of all of them in-house.
Thus DEC is attempting to find places that are working on the more
important of these languages, and they are funding efforts to develop
large address versions.  They are sponsoring us for Lisp, and Utah
for C.  Pascal is being done in a slightly complex fashion.  (In fact
some of our support from DEC is for Pascal.)

DEC does not expect to make money directly from these projects.  We will
maintain control over the software we develop, and could sell support
for it if we wanted to. We are, of course, expected to make the software
widely available. (Most likely we will submit it to DECUS but also
distribute it ourselves.)  What DEC gets out of it is that the large
address space DEC-20 will have a larger variety of software available
for it than otherwise.  I believe this will be an important point for
them in the long run, since no one is going to want to buy a machine for
which only the Fortran compiler can generate programs larger than 256K.
Thus they are facing the following facts:
  - they can't do things in house nearly as cheaply as universities
	can do them.
  - universities are no longer being as well funded to do language
	development, particularly not for the DEC-20.

			How will we go about it?

We have sufficient funding for one full-time person and one RA.  Both
DEC and Rutgers are very slow about paperwork.  But these people should
be in place sometime early this semester.  The implementation will
involve a small kernel, in assembly language, with the rest done in
Lisp.  We will get the Lisp code from CMU, and so will only have to do
the kernel.  This project seems to be the same size as the Elisp
project, which was done within a year using my spare time and a month of
so of Josh's time.  It seems clear that we have sufficient manpower. (If
you think maybe we have too much, I can only say that if we finish the
kernel sooner than planned, we will spend the time working on user
facilities, documentation, and helping users here convert to it.) CMU
plans to finish the VAX project in a year, with a preliminary version in
6 months and a polished release in a year.  Our target is similar.
-------