[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Rutgers lisp development project
- To: bboard at RUTGERS, griss at UTAH-20, admin.mrc at SU-SCORE, jsol at RUTGERS
- Subject: Rutgers lisp development project
- From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
- Date: Thu, 14 Jan 1982 04:44:00 -0000
- Mail-from: ARPANET site RUTGERS rcvd at 13-Jan-82 2146-PST
- Remailed-date: 14 Jan 1982 1622-PST
- Remailed-from: Mark Crispin
- Remailed-to: Feigenbaum at SUMEX-AIM, REG at SU-AI
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
- 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.