Re: adding to kernel

[Fahlman at CMU-20C]

In reply to GJC's recent message:

It is hard to comment on whether NIL is closer to being released than
other Common Lisp implementations, since you don't give us a time
estimate for NIL, and you don't really explain what you mean by
"released".  I understand that you have something turning over on
various machines at MIT, but it is unclear to me how complete this
version is or how much work has to be done to make it a Common Lisp
superset.  Also, how much manpower do you folks have left?

The PERQ implementation of Spice Lisp is indeed on our front burner.
Unfortumately, we do not yet have an instance of the PERQ 1a processor
upon which to run this.  The PERQ microcode is essentially complete and
has been debugged on an emulator.  The rest of the code, written in
Common Lisp itself, is being debugged on a different emulator.  If we
get get the manual settled soon and if 3RCC delivers the 1a soon, we
should have a Spartan but usable Common Lisp up by the start of the
summer.  The Perq 1a wil probably not be generally available until
mid-summer, given the delays in getting the prototype together.

By summer's end we should have an Emacs-like editor running, along with
some fairly nice debugging tools.  Of course, the system will be
improving for a couple of years beyond that as additional user amenities
appear.  I have no idea how long it will take 3RCC to start distributing
and supporting this Lisp, if that's what you mean by "release".  Their
customers might force them to move more quickly on this than they
otherwise would, but they have a lot of infrastructure to build -- no
serious Lispers over there at present.

As for your "unstated assumptions":

1. The amount of runtime error checking done by compiled code must be
left up to the various implementations, in general.  A machine like the
Vax will probably do less of this than a microcoded implementation, and
a native-code compiler may well want to give the user a compile-time
choice between some checking and maximum speed.  I think that the white
pages should just say "X is an error" and leave the question of how much
checking is done in compiled code to the various implementors.

2. The question of how (or whether) the user can debug compiled code is
also implementation-dependent, since the runtime representations and
stack formats may differ radically.  In addition, the user interface for
a debugging package will depend on the type of display used, the
conventions of the home system, and other such things, though one can
imagine that the debuggers on similar environments might make an effort
to look the same to the user.  The white pages should probably not
specify any debugging aids at all, or at most should specify a few
standard peeking functions that all implementations can easily support.

I agree that any Common Lisp implementation will need SOME decent debugging
aids before it will be taken seriously, but that does not mean that this
should be a part of the Common Lisp standard.

-- Scott
-------