Re: adding to kernel

[Kim.fateman at Berkeley]

There is a difference between the "common lisp core" and the
"kernel" of a particular implementation.  The common lisp core
presumably would have a function which obtains the time.  Extended
common lisp might convert the time to Roman numerals.  The kernel
would have to have a function (in most cases, written in something
other than lisp) which obtains the time from the hardware or
operating system.  I believe that the common lisp core should be
delineated, and the extended common lisp (written in common lisp core)
should be mostly identical from system to system.  What I would like
to know, though, is what will be required of the kernel, because it
will enable one to say to a manufacturer, it is impossible to write
a common lisp for this architecture because it lacks (say) a real-time
clock, or does not support (in the UNIX parlance) "raw i/o", or

perhaps multiprocessing...

I hope that the results of common lisp discussions become available for
less than the $10k (or more) per cpu that keeps us at Berkeley from
using Scribe.  I have no objection to a maintenance organization, but
I hope copies of relevant programs (etc) are made available in an
unmaintained form for educational institutions or other worthy types.

Do the proprietor(s) of NIL think it is a "common lisp implementation"?
That is, if NIL and CL differ in specifications, will NIL change, or
will NIL be NIL, and a new thing, CL emerge?  If CL is sufficiently
well defined that, for example, it can be written in Franz Lisp with
some C-code added, presumably a CL compatibility package could be
written.  Would that make Franz a "common lisp implementation"?
(I am perfectly happy with the idea of variants of Franz; e.g. users
here have a choice of the CMU top-level or the (raw) default; they
can have a moderately interlisp-like set of functions ("defineq" etc.)
or the default maclisp-ish.  ).