Martin's questions

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

1. What LISP or LISPs do you currently use?

Common Lisp (Spice Lisp) on a Perq.  Occasionally also use Zetalisp on
3600 and Maclisp on Dec-20.

2. Are you primarily a user or an implementor?

Implementor

4. If you are a common LISP user or implementor, do you have a plan to
   provide a compatibility route for "foreign" LISPS, such as by
   mechanical translation, or compatibility module?

No serious plans at present.  Several people here at CMU have converted
large Franz Lisp programs to Common Lisp, and we might be able to
package up the things they found they needed.  We're working on a
portable flavor system, which could be viewed as a part of a Zetalisp
compatibility package or as an extension to Common Lisp.

5. If your plan includes the identification of a subset CL
   (perhaps because you only need or can only afford to implement
    a subset on your machine, in your compatibility module, or
    your translator), 
   could you summarize what criteria you are using to define your subset?

We have no need for a subset.  Rob Maclachlan has already developed a
technique for flushing any unused code from a Perq core image, giving a
dramatic size reduction for delivered stand-alone products.


7. Do you see a single subset as sufficient, or do you envision a family
   of subsets, appropriate for different reasons?

The only need I see for a true subset is for small machines without
virtual memory, and even there they might get something approximating
the full language by a sort of autoload technique.  In any event, such
system will be so tight that the builders will want to put in exactly
what their users need, and not some standard mix.  For small expert
systems, you need one mix, for education you need another, if your
machine supports mouse-type graphics, another, if you want to build in
an Emacs, yet another.  The speed-space tradeoffs are tricky, and
will be different for each tiny machine and each market.  Maybe here and
there we will find cases enough alike that several manufacturers want to
agree on a common subset, or someone will set a de facto standard by
getting there first and doing a good job.

A different issue is the identification of a small kernel that, if you
can support it, you can load the rest of Common Lisp as portable code.
This is an interesting implementation technique, and we will be happy to
help people identify such kernels, but again the
time/space/coding-effort tradoff will be different for every machine,
depending on its constraints and whether it is trying to sit on top of
PSL, Interlisp, the raw hardware, or something else.  Fortunately, no
standard is needed here, since on the surface all of these langauges
will look like real Common Lisp.

8. Do you have a subset proposal ready to present to this group, or are
   you working on one?

Yes: no official subsets, but let's divide Common Lisp into standard
chunks so that people can say what it is that they do or do not
implement.  (The validation suite should reflect these chunks.)  Somone
might support "full Common Lisp minus floating point and complex
numbers, and with only partial support for packages" or something like
that.

-- Scott