perm filename COMMON.MSG[COM,LSP]22 blob sn#724666 filedate 1983-08-31 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00026 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00005 00002	
C00006 00003	∂28-Jul-83  1912	FAHLMAN@CMU-CS-C.ARPA 	ERROR SIGNALLING FUNCTIONS 
C00009 00004	∂28-Jul-83  2130	@MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN 	Non-evaluated error message in ASSERT    
C00011 00005	∂28-Jul-83  2155	WHOLEY@CMU-CS-C.ARPA 	Non-evaluated error message in ASSERT 
C00013 00006	∂29-Jul-83  0607	GBROWN@DEC-MARLBORO.ARPA 	ERROR SIGNALLING FUNCTIONS   
C00016 00007	∂29-Jul-83  0807	FAHLMAN@CMU-CS-C.ARPA 	Non-evaluated error message in ASSERT
C00019 00008	∂29-Jul-83  1338	@MIT-MC:MOON%SCRC-TENEX%MIT-MC@SU-DSN 	Non-evaluated error message in ASSERT    
C00021 00009	∂29-Jul-83  2131	Guy.Steele@CMU-CS-A 	ASSERT and CHECK-TYPE   
C00022 00010	∂05-Aug-83  1309	@USC-ECL,@MIT-XX:BSG@SCRC-TENEX 	File open options
C00025 00011	∂09-Aug-83  0809	@USC-ECL,@MIT-XX:BSG@SCRC-TENEX 	File opening, :TRUNCATE    
C00027 00012	∂14-Aug-83  1216	FAHLMAN@CMU-CS-C.ARPA 	Things to do
C00036 00013	∂15-Aug-83  1251	@MIT-MC:BENSON@SPA-NIMBUS 	Looping constructs
C00039 00014	∂15-Aug-83  2305	@MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN 	Things to do    
C00043 00015	∂15-Aug-83  2342	FAHLMAN@CMU-CS-C.ARPA 	Things to do
C00045 00016	∂16-Aug-83  0038	@MIT-MC:Cassels@SCRC-TENEX 	Things to do
C00047 00017	∂16-Aug-83  2131	@MIT-MC:HIC@SCRC-TENEX 	Things to do    
C00050 00018	∂16-Aug-83  2324	HEDRICK@RUTGERS.ARPA 	Re: Things to do  
C00052 00019	∂17-Aug-83  0848	@MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN 	Re: Things to do 
C00054 00020	∂18-Aug-83  1006	@MIT-MC:benson@SCRC-TENEX 	What to do next   
C00063 00021	∂18-Aug-83  1134	@MIT-MC:MOON@SCRC-TENEX 	subsetting
C00065 00022	∂18-Aug-83  1226	HEDRICK@RUTGERS.ARPA 	Re: subsetting    
C00066 00023	∂18-Aug-83  1224	HEDRICK@RUTGERS.ARPA 	Re: What to do next    
C00070 00024	∂18-Aug-83  1221	FAHLMAN@CMU-CS-C.ARPA 	What to do next  
C00086 00025	∂18-Aug-83  1349	@MIT-MC:MOON@SCRC-TENEX 	subsetting
C00087 00026	∂18-Aug-83  1352	@MIT-MC:benson@SCRC-TENEX 	What to do next   
C00096 ENDMK
C⊗;
∂28-Jul-83  1912	FAHLMAN@CMU-CS-C.ARPA 	ERROR SIGNALLING FUNCTIONS 
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 Jul 83  19:12:13 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 28 Jul 83 22:12:52-EDT
Date: Thu, 28 Jul 1983  22:12 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To:   GBROWN@DEC-MARLBORO.ARPA
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: ERROR SIGNALLING FUNCTIONS
In-reply-to: Msg of Thu 28 Jul 83 11:32:42-EDT from GBROWN at DEC-MARLBORO.ARPA


A part of Paul's note that I agree with is that, in retrospect, I don't
think that we want to have error-signalling forms that take unevaluated
string args.  In most cases we will want to stick some constant string
in there, but there may well be cases where we want to evaluate any such
arg.  A function that goes off somewhere to find a string in the proper
natural language is just one such application.  Since the string arg in
ASSERT is used as a syntactic marker, we would have to change that
function's syntax to fix this -- the pre-string arguments would have to
be encased in a list or something like that.

We probably should think about fixing this in the second edition -- it
is not of such earth-shaking importance that we should consider
unfreezing edition 1 to put this change in.  As others have pointed out,
ASSERT is just a convenient abbreviation, not a primitive.

-- Scott

∂28-Jul-83  2130	@MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN 	Non-evaluated error message in ASSERT    
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Jul 83  21:30:38 PDT
Received: from SCRC-BULLDOG by SCRC-TENEX with CHAOS; Fri 29-Jul-83 00:29:15-EDT
Date: Friday, 29 July 1983, 00:30-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Non-evaluated error message in ASSERT
To: COMMON-LISP@SU-AI
In-reply-to: The message of 28 Jul 83 22:12-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>

When I first proposed the current syntax of ASSERT, I asked if
anyone wanted to change the syntax to allow the error message to
be evaluated, and no one said yes.  I would be perfectly happy
to make that change and regard it as an erratum in the manual.

The current syntax is

	(ASSERT test-form [reference*] [format-string] [format-arg*])

The new syntax would be

	(ASSERT test-form ([reference*]) [format-string] [format-arg*])

∂28-Jul-83  2155	WHOLEY@CMU-CS-C.ARPA 	Non-evaluated error message in ASSERT 
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 Jul 83  21:54:58 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 29 Jul 83 00:55:44-EDT
Date: Fri, 29 Jul 1983  00:55 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: Non-evaluated error message in ASSERT
In-reply-to: Msg of 29 Jul 1983 00:30-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>

Of course, with the current definition of ASSERT, one can still compute
format-strings by using "~?", format indirection...

∂29-Jul-83  0607	GBROWN@DEC-MARLBORO.ARPA 	ERROR SIGNALLING FUNCTIONS   
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 29 Jul 83  06:07:34 PDT
Date: Fri 29 Jul 83 09:06:44-EDT
From: GBROWN@DEC-MARLBORO.ARPA
Subject: ERROR SIGNALLING FUNCTIONS
To: COMMON-LISP@SU-AI.ARPA

Well, I certainly want to thank everyone for taking the time to read
my message and give it some thought.  I can tell that it's going to
be refreshing to work on Common Lisp in an environment where a variety of
people openly discuss the issues (I am just about to join the AI 
group at Digital).

It is clear now that I was coming from a different direction.  I tend
to implement a simple internal error reporting facility for an
application, and then spend most of my time on the user interface.
Thus my reaction to the functions was slanted in the direction of the
user.  The functions are quite good for internal error reporting, and
it's great that developers won't have to reinvent them every time.

I do suggest that we take Dave Moon up on his willingness to change the
definition of check-type and assert so that they can evaluate their
message strings.  We've had some success at Digital with message file
translation, so we might want to do that with Lisp applications.  One
can still put the messages in the source; a fancy macro can do the
dirty work.

I also suggest that we think a little about how declarations interact
with the key forms of these functions.

Any day now we'll get our Lisp Machine.  Thanks again.

- Paul C. Anagnostopoulos
-------

∂29-Jul-83  0807	FAHLMAN@CMU-CS-C.ARPA 	Non-evaluated error message in ASSERT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Jul 83  08:07:23 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 29 Jul 83 11:07:58-EDT
Date: Fri, 29 Jul 1983  11:07 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To:   David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: Non-evaluated error message in ASSERT
In-reply-to: Msg of 29 Jul 1983 00:30-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>


If there are no objections to the proposed change to the syntax of
ASSERT, I propose that we let Guy decide whether this "erratum" can go
into the manual at this point without undue disruption of the
proofreading/editing/production process.  While changing anything that
is widely used would be unacceptable to us at this time, ASSERT is not
currently being used much in our code, and the proposed change is
trivial.  CHECK-TYPE would also be changed to eval its string, but this
change is upward-compatible, or nearly so.  Guy should give us a clear
go/no-go decision on this change as soon as possible.

I do remember Moon's query on this, and also that I didn't think very
long about its implications, given the amount of stuff that was being
dealt with just then.

-- Scott

∂29-Jul-83  1338	@MIT-MC:MOON%SCRC-TENEX%MIT-MC@SU-DSN 	Non-evaluated error message in ASSERT    
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 Jul 83  13:37:48 PDT
Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Fri 29-Jul-83 16:34:38-EDT
Date: Friday, 29 July 1983, 16:35-EDT
From: David A. Moon <MOON%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Non-evaluated error message in ASSERT
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: COMMON-LISP@SU-AI
In-reply-to: The message of 29 Jul 83 11:07-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>

CHECK-TYPE already does evaluate its optional third argument (error message).
If the manual doesn't say this, it's a mistake in the manual.

∂29-Jul-83  2131	Guy.Steele@CMU-CS-A 	ASSERT and CHECK-TYPE   
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 29 Jul 83  21:31:18 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 30 Jul 83 00:23:39 EDT
Date: 30 Jul 83 0027 EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: ASSERT and CHECK-TYPE

Per Moon's remark, that the manual states that CHECK-TYPE does not evaluate
the error-message argument is an error.  CHECK-TYPE should evaluate its
optional argument form.
ASSERT should have the syntax
	ASSERT  test-form [ ( {place}* ) [ string {arg}* ] ]
--Guy

∂05-Aug-83  1309	@USC-ECL,@MIT-XX:BSG@SCRC-TENEX 	File open options
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Aug 83  13:09:01 PDT
Received: from MIT-XX by USC-ECL; Fri 5 Aug 83 13:09:30-PDT
Received: from SCRC-BEAGLE by SCRC-SPANIEL with CHAOS; Fri 5-Aug-83 15:50:05-EDT
Date: Friday, 5 August 1983, 15:50-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: File open options
To: Common-Lisp%su-ai at USC-ECL

The Laser Manual speaks of the :IF-EXISTS options :RENAME,
:RENAME-AND-DELETE as though they do their renaming and deleting at open
time.  It goes out of its way to say that :SUPERSEDE "destroys" the
existing file at successful close time.  The former being unreasonable,
I decided that the Lisp Machine local file system would continue to
implement all of these concepts at successful close time.  It keeps the
real file open under a funny name until then.  The only place it could
possibly screw up is a direct access, interlocked, multi-process, shared
file of a kind that we currently don't have.
I guess I'm just thinking out loud, or asking for an adjudication
on the legality of such a decision.

While we are on the subject, should anything be said about open 
':direction ':output ':if-exists ':overwrite closing in abort mode?
Should the file go away?

∂09-Aug-83  0809	@USC-ECL,@MIT-XX:BSG@SCRC-TENEX 	File opening, :TRUNCATE    
Received: from USC-ECL by SU-AI with TCP/SMTP; 9 Aug 83  08:09:27 PDT
Received: from MIT-XX by USC-ECL; Tue 9 Aug 83 08:07:50-PDT
Received: from SCRC-BEAGLE by SCRC-SPANIEL with CHAOS; Tue 9-Aug-83 11:04:41-EDT
Date: Tuesday, 9 August 1983, 11:04-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: File opening, :TRUNCATE
To: Common-Lisp%SU-AI at USC-ECL
Cc: File-protocol at SCRC-TENEX

Was it ever proposed or rejected that there be a :IF-EXISTS
:TRUNCATE, being like :OVERWRITE, except that the file content
is effectively set to empty before writing starts?  There is
need for such a thing, and it is a natural behavior on many
systems.  

The default :IF-EXISTS of :ERROR is not useful on file systems
that do not have versions (note that a version of :NEWEST
changes the default to :NEW-VERSION).   We propose that the
default :IF-EXISTS be changed to :SUPERSEDE for file sytems
that do not have versions.   

Is there any reason why :IF-EXISTS is ignored in :OUTPUT/:IO
instead of generating an error?  

∂14-Aug-83  1216	FAHLMAN@CMU-CS-C.ARPA 	Things to do
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 14 Aug 83  12:16:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 14 Aug 83 15:16:47-EDT
Date: Sun, 14 Aug 1983  15:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp @ SU-AI.ARPA
Subject: Things to do


A bunch of things were put off without decisions or were patched over in
the effort to get agreement on the first edition.  Most of the people
who have been intensively involved in the language design will be tied
up for another couple of months getting their implementations up to spec
and tweaking them for performance.  However, it is perhaps not too soon
to begin thinking about what major additions/changes we want to get into
the second edition, so that those who want to make proposals can begin
preparing them and so that people can make their plans in light of what
is likely to be coming.

Here's a list of the major things that I see on the agenda for the next
year or so.  Some are yellow-pages packages, some have deep roots
and require white-pages support, and some are so pervasive that they
will probably migrate into the white pages after a probationary period
in yellow-land.  I'm sure I'm forgetting a few things that have already
been suggested.  I'm also sure that people will have some additional
proposals to make.  I am not including very minor and trivial changes
that we might want to make in the language as we gain some experience
with it.

1. Someone needs to implement the transcendental functions for complex
numbers in a portable way so that we can all use these.  The functions
should be parameterized so that they will work for all the various
floating-point precisions that implementations might offer.  The design
should be uncontroversial, since it is already specified in the manual.
I don't think we have any volunteers to do this at present.

2. We need to re-think the issue of function specs, and agree on what
should go into the white pages next time around.  Moon's earlier
proposal, or some subset of it, is probably what we want to go with.

3. At one point HIC offered to propose a minimal set of white-pages
support for efficient implementation of a portable flavor system, and to
supply the portable part.  The white-pages support would also be usable
by other object-oriented paradigms with different inheritance schemes
(that's the controversial part).  After a brief exchange of messages,
HIC got super-busy on other matters and we haven't heard much since
then.  Either HIC or someone else needs to finish this proposal, so that
we can put in the low-level support and begin playing with the portable
implementation of flavors.  Only after more Common Lisp users have had
some opportunity to play with flavors will it make sense to consider
including them (or some variation) in the white pages.  There is a lot
of interest in this out in user-land.

4. We need some sort of iteration facility more powerful than DO.  The
existing proposals are some extensively cleaned-up revision of LOOP and
Dick Waters' LETS package.  There may be some other ideas out there as
well.  Probably the best way to proceed here is for the proponents of
each style to implement their package portably for the yellow pages and
let the customers decide what they like.  If a clear favorite emerges,
it will probably be absorbed into the white pages, though this would not
preclude personal use of the other style.  None of these things requires
white-pages support -- it is just a matter of what we want to encourage
users to use, and how strongly.

5. A good, portable, user-modifiable pretty printer is needed, and if it
were done well enough I see no reason not to put the user-visible
interface in the white pages next time around.  Waters' GPRINT is one
candidate, and is being adopted as an interim pretty-printer by DEC.
The last time I looked, the code for that package was impenetrable and
the interface to it was excessively hairy, but I've heard that it has
been simplified.  Maybe this is what we want to go with.  Other options?

6. We need to work out the business of taxonomic error-handling.  Moon
has a proposal in mind, I believe.  A possible problem is that this
wants to be white-pages, so if it depends on flavors it gets tied up
with the issue of making flavors white-pages as well.

7. The Hemlock editor, a public-domain Emacs-clone written in portable
Common Lisp, is now running on the Perq and Vax implementations.  We
have a lot of additional commands and modes to implement and some tuning
to do, but that should happen fairly rapidly over the next few months.
Of course, this cannot just be moved verbatim to a new implementation
and run there, since it interacts closely with screen-management and
with the file system.  Once Hemlock is polished, it will provide a
reasonable minimum editing/top-level environment for any Common Lisp
implementation that takes the trouble to adapt it to the local system.
This should eliminate the need for hairy rubout-handlers, interlispy
top-levels, S-expression editors, and some other "environment" packages.
We plan to add some version of "info mode" at some point and to get the
Common Lisp Manual and yellow pages documents set up for tree-structured
access by this package, but that won't happen right away.

8. Someone ought to put together a reasonable package of macro-writer's
aids: functions that know which things can be evaluated multiple times
without producing side-effects, type-analysis hacks, and other such
goodies.

If you have items to add to this list, let me know.

-- Scott

∂15-Aug-83  1251	@MIT-MC:BENSON@SPA-NIMBUS 	Looping constructs
Received: from MIT-MC by SU-AI with TCP/SMTP; 15 Aug 83  12:50:58 PDT
Date: Monday, 15 August 1983, 12:29-PDT
From: Eric Benson <BENSON at SPA-Nimbus>
Subject: Looping constructs
To: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>,
    common-lisp at SU-AI.ARPA
In-reply-to: The message of 14 Aug 83 12:16-PDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>

Okay, I'll jump right in...

I believe that LOOP and LetS can coexist peacefully in the same world.
They deal with two different problems in very different ways.  LetS
allows APL-style processing of "sequences," (unrelated to the Common
Lisp sequence concept) with an expression based syntax.  It is designed
so that sequences are not actually created as data structures, rather
existing conceptually as intermediate values.  Such operations as
merging, sorting and concatentation do not fit within its paradigm.
LOOP, on the other hand, is intended to extend (all) the iteration
constructs found in other languages to Lisp, with a keyword based
syntax.  This kitchen-sink-ism and non-Lispy syntax seems to offend some
purists, but there are many iterative programs which could not be
expressed at all using LetS, and only painfully using DO, which are
quite amenable to treatment with LOOP.  Chacun a son gout.

(LOOP FOR EVERYONE IN COMMON-LISP DO (SEND EVERYONE :THIS-MESSAGE))

∂15-Aug-83  2305	@MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN 	Things to do    
Received: from MIT-MC by SU-AI with TCP/SMTP; 15 Aug 83  23:05:47 PDT
Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Tue 16-Aug-83 02:01:39-EDT
Date: Tuesday, 16 August 1983, 01:56-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Things to do
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: common-lisp@SU-AI
In-reply-to: The message of 14 Aug 83 15:16-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>

I think we plan to contribute to this, but I at least will not have time to
get near this stuff for at least a couple of months.

3. Portable flavor system / white-pages message-passing substrate.
I think we will find one or more people at Symbolics interested in finishing
the proposal HIC made long ago and implementing it on our machines.

4. LOOP and LetS
We should have both of these available in Common Lisp, and both of them should
be reimplemented.  I've intended for almost two years now to do this for LOOP,
so you know how much to believe me when I say I will get back to this soon.
As CL implementations become available at MIT in a few months someone will
no doubt be found to fix LetS.

5. Pretty-printing
DLW is interested in rewriting Waters' GPRINT.  I'll let him speak for himself
on what the status of this is.

6. Taxonomic event handling.
I have a proposal for this, which is suffiently abstract that it could be
implemented on something other than flavors (although clearly the right substrate
for it is flavors).  The proposal is not at all finished, but I will send it
out in a couple of months.

8. Macro-writer's aids.
I have most of this stuff, written in something pretty close to straight Common Lisp.
The one thing I don't have is type-analysis, although I expect that would be
easy to build on top of the other tools.  In a couple of months I'll see about 
making this stuff portable and available.

To add to your list:

A portable interpreted-code stepper that uses *EVALHOOK* and *APPLYHOOK*.

A portable or near-portable TRACE package.

A variety of macro memoization schemes, using *MACROEXPAND-HOOK*.
These aren't as trivial as they seem at first blush.

More general destructuring facilities (I have an unfinished proposal).

A portable defstruct implemementation.

Portable floating-point read and print.

∂15-Aug-83  2342	FAHLMAN@CMU-CS-C.ARPA 	Things to do
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 15 Aug 83  23:42:04 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 16 Aug 83 02:42:18-EDT
Date: Tue, 16 Aug 1983  02:42 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To:   David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Things to do
In-reply-to: Msg of 16 Aug 1983 01:56-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>


Dave,

Glad to hear that you folks are interested in doing a number of things
on the list.  Nobody is expecting super-quick action on any of this.  As
I said, this is just a bit of pre-planning for things to do once our
respective implementations are stable.

Of the things on your shopping list, STEP, TRACE, and DEFSTRUCT are all
working here and could be made portable easily enough.  They may not be
hairy enough (or featureful enough) for everyone's taste.

I'll have to look at our floating read and print, but I doubt that they
are easy to make portable.

-- Scott

∂16-Aug-83  0038	@MIT-MC:Cassels@SCRC-TENEX 	Things to do
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Aug 83  00:38:21 PDT
Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Tue 16-Aug-83 03:35:30-EDT
Date: Tuesday, 16 August 1983, 03:35-EDT
From: Robert A. Cassels <Cassels at SCRC-TENEX>
Subject: Things to do
To: Fahlman at CMU-CS-C.ARPA, Moon%SCRC-TENEX%MIT-MC at SU-DSN.ARPA
Cc: common-lisp at SU-AI.ARPA
In-reply-to: The message of 16 Aug 83 02:42-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>

    Date: Tue, 16 Aug 1983  02:42 EDT
    From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>

    I'll have to look at our floating read and print, but I doubt that they
    are easy to make portable.

Ours can be made portable without too much trouble (at some loss of
efficiency).  It probably wants a few extra features.  I figured I'd
wait for Steele's, in the hope that he's figured out more elegant
solutions to the problems than I did.

∂16-Aug-83  2131	@MIT-MC:HIC@SCRC-TENEX 	Things to do    
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Aug 83  21:31:41 PDT
Received: from SCH-STYX by SCRC-TENEX with CHAOS; Wed 17-Aug-83 00:25:26-EDT
Date: Tuesday, 16 August 1983, 21:30-PDT
From: Howard I. Cannon <HIC at SCRC-TENEX>
Subject: Things to do
To: Fahlman at CMU-CS-C.ARPA
Cc: common-lisp at SU-AI.ARPA
In-reply-to: The message of 14 Aug 83 12:16-PDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>

    3. At one point HIC offered to propose a minimal set of white-pages
    support for efficient implementation of a portable flavor system, and to
    supply the portable part.  The white-pages support would also be usable
    by other object-oriented paradigms with different inheritance schemes
    (that's the controversial part).  After a brief exchange of messages,
    HIC got super-busy on other matters and we haven't heard much since
    then.  Either HIC or someone else needs to finish this proposal, so that
    we can put in the low-level support and begin playing with the portable
    implementation of flavors.  Only after more Common Lisp users have had
    some opportunity to play with flavors will it make sense to consider
    including them (or some variation) in the white pages.  There is a lot
    of interest in this out in user-land.

My schedule is too unpredictable at this point to make a comitment, but
I intend to be doing some new development on Flavors this fall, and can
likely finish up a reasonable proposal within the next few months.  If
there's a 90% chance I can get something through, then I'll schedule
it...

∂16-Aug-83  2324	HEDRICK@RUTGERS.ARPA 	Re: Things to do  
Received: from RUTGERS by SU-AI with TCP/SMTP; 16 Aug 83  23:24:15 PDT
Date: 17 Aug 83 00:43:32 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Things to do
To: HIC%SCRC-TENEX@MIT-MC.ARPA
cc: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Howard I. Cannon <HIC at SCRC-TENEX>" of 17 Aug 83 00:36:25 EDT

An alternative might be
  movei n,2
  pushj p,@[fadr block]
where the address in the fadr block was indexed by N.  That would still
save testing and dispatching within the function itself, but would
avoid adding 4 words to the FADR block.  What do you think?
-------

∂17-Aug-83  0848	@MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN 	Re: Things to do 
Received: from MIT-MC by SU-AI with TCP/SMTP; 17 Aug 83  08:48:03 PDT
Date: 17 Aug 1983 1049-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Things to do
To: Moon%SCRC-TENEX%MIT-MC@SU-DSN
cc: Fahlman%CMU-CS-C@SU-DSN, common-lisp@SU-AI
In-Reply-To: The message of Tuesday, 16 August 1983, 01:56-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>

I have done 90% of the work of rewriting GPRINT completely in
modern Lisp style, which also makes it perform
better.  I still have to do the "last 10%" with all that that
implies.  Converting it to Common Lisp also has to be done
but it clearly easy.  I don't think when I'll have time to work on this
more, though.  Keep in touch.
-------

∂18-Aug-83  1006	@MIT-MC:benson@SCRC-TENEX 	What to do next   
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83  10:06:04 PDT
Date: Thursday, 18 August 1983  11:54-EDT
From: dlw at SCRC-TENEX, benson at SCRC-TENEX
Subject: What to do next
To:   fahlman at cmuc
Cc:   common-lisp at su-ai


Scott, I appreciated your summary of pending issues in Common Lisp, and
I certainly think we should proceed to work on these things.  However, I
think that the "next things to do", after we get out the initial real
Common Lisp manual, are:

(1) Create a Common Lisp Virtual Machine specification, and gather a
body of public domain Lisp code which, when loaded into a proto-Lisp
that meets the spec, produces a complete Common Lisp interpreter that
meets the full language spec.  (This doesn't address the portable
compiler problem.)

(2) Establish an official Common Lisp subset, suitable for
implementation on 16-bit microcomputers such as the 68000 and the 8088.
I understand that Gabriel is interested in 68000 implementations, and I
am trying to interest Bob Rorscharch (who implemented IQLISP, which is
an IBM PC implementation of a UCILISP subset) in converting his product
into a Common Lisp implementation.

There are a lot of problems with subsetting.  You can't leave out
multiple values, beacuse several primitives return multiple values and
you don't want to omit all of these primitives (and you don't want to
discourage the addition of new primitives that return multiple values,
in future versions of Common Lisp).  You can't leave out packages, at
least not entirely, because keywords are essential to many functions.
And many things, if removed, would have to be replaced by something
significantly less clean.  We'd ideally like to remove things that (a)
can be removed without creating the need for an unclean simpler
substitute, and (b) aren't used by the rest of the system.  In other
words, we have to find modular chunks to break off.  And, of course,
any problem that works in the subset has to work and do exactly the
same thing in full Common Lisp, unless the program has some error
(in the "it is an error" sense).  The decision as to what goes
in and what goes out should be made in light of the fact that
an implementation might be heavily into "autoloading".

Complex numbers can easily be omitted.

The requirement for all the floating point precisions can be
omitted.  Of course, Common Lisp is flexiable in this regard anyway.

Rational numbers could be left out.  They aren't hard, per se, but
they're just another thing to do.  The "/" function on two integers
would have to signal an error.

Packages could be trimmed down to only be a feature that supplies
keywords; most of the package system might be removable.

Lexical scoping might possibly be removable.  You could remove support
for LABELS, FLET, and MACROLET.  You can't remove internal functions
entirely (i.e. MAPCAR of a lambda-expression can't be removed) but they
might have some restrictions on them.

Adjustable arrays could be removed.  Fill pointers could go too,
although it's not clear that it's worth it.  In the extreme, you could
only have simple arrays.  You could even remove multi-D arrays
entirely, or only 1-D and 2-D.

Several functions look like they might be big, and aren't really
required.  Some candidates: COERCE, TYPE-OF, the hard version
of DEFSETF (whatever you call it), LOOP, 

TYPEP and SUBTYPEP are hard to do, but it's hard to see how
to get rid of the typing system!  SUBTYPEP itself might go.

Multiple values would be a great thing to get rid of in the subset, but
there are the Common Lisp primitives that use multiple values.  Perhaps
we should add new primitives that return these second values only, for
the benefit of the subset, or something.

Catch, throw, and unwind-protect could be removed, although they're
sure hard to live without.

Lots of numeric stuff is non-critical:  GCD, LCM, CONJUGATE, the
exponentials and trascendentals, rationalize, byte manipulation, random
numbers.

The sequence functions are a lot of work and take a lot of room in your
machine.  It would be nice to do something about this.  Unfortunately,
simply omitting all the sequence functions takes away valuable basic
functionality such as MEMQ.  Perhaps the subset could leave out some of
the keywords, like :test and :test-not and :from-end.

Hash tables are not strictly necessary, although the system itself
are likely to want to use some kind of hash tables somewhere,
maybe not the user-visible ones.

Maybe some of the defstruct options could be omitted, though I don't
think that getting rid of defstruct entirely would be acceptable.

Some of the make-xxx-stream functions are unnecessary.

Some of the hairy reader syntax is not strictly necessary.  The circular
structure stuff and load-time evaluation are the main candidates.

The stuff to allow manipulation of readtables is not strictly necessary,
or could be partially restricted.

Some of the hairy format options could be omitted.  I won't go into
detail on this.

Some of the hairy OPEN options could go, although I'd hate to be the one
to decide which options are the non-critical ones.  Also some of the
file operations (rename, delete, attribute manipulation) could go.

The debugging tools might be optional although probably they just
get autoloaded anyway.

∂18-Aug-83  1134	@MIT-MC:MOON@SCRC-TENEX 	subsetting
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83  11:33:52 PDT
Date: Thursday, 18 August 1983  14:26-EDT
From: MOON at SCRC-TENEX
To:   dlw at SCRC-TENEX, benson at SCRC-TENEX
Cc:   common-lisp at su-ai
Subject: subsetting
In-reply-to: The message of 18 Aug 1983  11:54-EDT from dlw at SCRC-TENEX, benson at SCRC-TENEX

Most (by no means all) of the things you suggest omitting are quite inexpensive
to include in an implementation that is optimized for space rather than speed.
I don't think it is a good idea to have something called "Common Lisp" that
omits large portions of the language.  All the special forms should be included.
Two good ways to fit into a smaller machine without sacraficing functionality
are to use "autoloading" for little-used functions and to not include things
only needed at compile time in the run-time environment (they can be "autoloaded"
when needed for debugging or interpretive execution, of course).  I think both
of these categories are probably very large in Common Lisp.

∂18-Aug-83  1226	HEDRICK@RUTGERS.ARPA 	Re: subsetting    
Received: from RUTGERS by SU-AI with TCP/SMTP; 18 Aug 83  12:26:45 PDT
Date: 18 Aug 83 15:23:50 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: subsetting
To: MOON%SCRC-TENEX@MIT-MC.ARPA
cc: dlw%SCRC-TENEX@MIT-MC.ARPA, benson%SCRC-TENEX@MIT-MC.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: Message from "MOON at SCRC-TENEX" of 18 Aug 83 14:26:00 EDT

Another approach is to use byte code instead of real machine code.
This can allow a significant space saving. 
-------

∂18-Aug-83  1224	HEDRICK@RUTGERS.ARPA 	Re: What to do next    
Received: from RUTGERS by SU-AI with TCP/SMTP; 18 Aug 83  12:24:32 PDT
Date: 18 Aug 83 15:20:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: What to do next
To: dlw%SCRC-TENEX@MIT-MC.ARPA, benson%SCRC-TENEX@MIT-MC.ARPA
cc: fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from "dlw at SCRC-TENEX, benson at SCRC-TENEX" of 18 Aug 83 11:54:00 EDT

In general I agree with you.  However let me point out:
  1) that you can simplify MV's to the point that implementation is 
trivial.  All you have to do is require that the caller of a function
never asks for more MV's than there really are.  (In particular, that
he never asks for MV's when there aren't any.)  This handles the most
useful cases.  Certainly it handles the case of calling system functions
that return MV's.  Then you require only a couple of primitives, 
probably MV-SETQ and MV-BIND.  You certainly do not do MV-LIST (because
you can't) nor MV-CALL.  The result is that you can implement MV's
by putting the values in the AC's or in global variables.  No 
additional mechanisms are needed.  I believe this is the right thing
to have done in the first place.  (Indeed I think the whole subset
is probably going to be more useful than the real language.)
  2) we do have a compiler that is probably about as portable as
you are going to get.  We use CMU's Spice Lisp compiler.  It produces
code for a stack-oriented microcoded machine.  We transform this
into code for a register-oriented machine.  The instruction set we
use is an extended version of Utah's CMACS, the final intermediate
representation used in PSL.  It is close enough to machine code that
we produce the actual machine code in LAP.  I am sure there ae
machines that we might have trouble with, but for the ones I am
used to, a couple of days playing with LAP should allow our code to
be loaded on any register-oriented machine.  The origial Spice Lap
code could probably be loaded on any stack-oriented machine.
-------

∂18-Aug-83  1221	FAHLMAN@CMU-CS-C.ARPA 	What to do next  
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Aug 83  12:20:52 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 18 Aug 83 15:21:42-EDT
Date: Thu, 18 Aug 1983  15:21 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To:   dlw%SCRC-TENEX@MIT-MC.ARPA, benson%SCRC-TENEX@MIT-MC.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: What to do next
In-reply-to: Msg of 18 Aug 1983  11:54-EDT from dlw at SCRC-TENEX, benson at SCRC-TENEX

    Date: Thursday, 18 August 1983  11:54-EDT

    (1) Create a Common Lisp Virtual Machine specification, and gather a
    body of public domain Lisp code which, when loaded into a proto-Lisp
    that meets the spec, produces a complete Common Lisp interpreter that
    meets the full language spec.  (This doesn't address the portable
    compiler problem.)

Our Spice Lisp implementation is currently serving exactly this need for
about 6 implementation efforts.  Instead of specifying a little Lisp kernel
that has to be implemented, we specify a byte-coded instruction set,
then provide Common Lisp written in Common Lisp (with some of these
byte-coded primitives sprinkled in), plus a compiler written in Common
Lisp that produces these byte codes.  All a prospective user has to
supply are either microcode for the byte-codes or a post-processor from
byte codes to their machine's native instruction set, plus the byte-code
primitives, GC, I/O, and the system interface stuff.  Of course, once
that is done, it is worth putting about a man-year of tuning into any
given implementation to make it run as well as possible.

So our SLGUTS document, along with our public-domain Lisp code and
compiler, do most of what the blue pages are supposed to do.  We are
currently polishing our system up so that it is legal, and in the
process we are cleaning up our compiler so that it will be easier to
replace the whole code-generator, if people would rather do that than
work from byte-codes.  We also plan a substantial cleanup on our
byte-code set, which is by now quite obsolete and creaky.

The next obvious step is to take all of this and turn it into a cleanly
packaged "implementor's kit".  That would reduce the amount of
hand-holding we would have to do and make the whole thing look more
portable.  I don't have much interest in taking this additional (largely
cosmetic) step, but would cooperate with anyone else who wants to do it.
Of course, if someone wants to build a better compiler/kit (ours is more
stack-oriented than is optimal on conventional architectures and does
not have all those hairy optimizations in it that real compiler hackers
love), that would be a good thing to do.

So I guess I see this as a mostly-solved problem and therefore not a
high-priority issue.

    (2) Establish an official Common Lisp subset, suitable for
    implementation on 16-bit microcomputers such as the 68000 and the 8088.

I'm a little dubious about this subsetting business.  It is true that
one could get rid of maybe half the virtual core image by judicious
trimming, though including a compiler or Hemlockish editor would push
you back up there.  Rather than worry a lot about trimming the Lisp and
about going from a big core image to autoload, maybe the time should be
spent figuring out how to fake a decent virtual memory system on these
machines.  It would be nice to have things like Format lurking out on
the floppies but virtually there, rather than gone but autoloadable.

A whole generation of people learned to hate Lisp because they tried to
prehistoric implementations without good debugging tools,
pretty-printing editors,and the other things that make Lisp a decent
programming environment.  Let's not repeat this and expose high-school
kids to the result.

One thing we might do, if we want Common Lisp programs to be deliverable
on micros with the minimum of memory, is to work on a system that goes
over a set of compiled files and builds a Lisp core image with only
these things and the Lisp facilities that they call included.  You would
develop on your Vax or 3600, but the turnkey expert system might then
run on a 68000-based machine with minimal disk.

Anyway, to respond to your suggestions:

    Complex numbers can easily be omitted.
[ Yep.  Should ahve been omitted from the real thing, and may still be
if nobody works up the enthusiasm to implement them.]

    The requirement for all the floating point precisions can be
    omitted.  Of course, Common Lisp is flexiable in this regard anyway.
[ Yeah.  The high-school version could leave them out altogether, and
all the trascendental functions, for a big saving. ]

    Rational numbers could be left out.  They aren't hard, per se, but
    they're just another thing to do.  The "/" function on two integers
    would have to signal an error.
[ This wouldn't save much -- GCD is all you need and that's not too big.
Maybe leave out the Float/rational conversions.]

    Packages could be trimmed down to only be a feature that supplies
    keywords; most of the package system might be removable.
[ Yeah.  Again it doesn't save much. ]

    Lexical scoping might possibly be removable.  You could remove support
    for LABELS, FLET, and MACROLET.  You can't remove internal functions
    entirely (i.e. MAPCAR of a lambda-expression can't be removed) but they
    might have some restrictions on them.
[ Lexical scoping doesn't cost much in space, but it slows down the
interpreter and adds much hair to the compiler.  If you want to save on
compiler space, let GO and RETURN be confined in the traditional way
(only to a cleanly surrounding block and not from a position that leaves
crud on the stack) and eliminate lexical closures and the FLET stuff.]

    Adjustable arrays could be removed.  Fill pointers could go too,
    although it's not clear that it's worth it.  In the extreme, you could
    only have simple arrays.  You could even remove multi-D arrays
    entirely, or only 1-D and 2-D.
[ This would save a fair amound in dispatching hair.  Not trying to
super-optimize for speed would also save a lot of space -- whether
that's a good trade depends on the machine and the applications.]

    Several functions look like they might be big, and aren't really
    required.  Some candidates: COERCE, TYPE-OF, the hard version
    of DEFSETF (whatever you call it), LOOP, 
[Yup.]

    TYPEP and SUBTYPEP are hard to do, but it's hard to see how
    to get rid of the typing system!  SUBTYPEP itself might go.
[Got to have TYPEP, but not the hairy compund types and booleans.
Subtypep is needed by the compiler but not much by user code.]

    Multiple values would be a great thing to get rid of in the subset, but
    there are the Common Lisp primitives that use multiple values.  Perhaps
    we should add new primitives that return these second values only, for
    the benefit of the subset, or something.
[If you're willing to cons when passing back multiples, or to limit the
number to, say, 3 values, it becomes easy to do.  I believe that only
our unfortunate time functions return more than a few values.]

    Catch, throw, and unwind-protect could be removed, although they're
    sure hard to live without.
[No, you've got to keep these.  They become easy to do if you don't have
to pass multiple back on the stack.]

    Lots of numeric stuff is non-critical:  GCD, LCM, CONJUGATE, the
    exponentials and trascendentals, rationalize, byte manipulation, random
    numbers.
[Leave in hyperbolic arctan, though -- every language needs at least one
function that nobody has ever tried.]

    The sequence functions are a lot of work and take a lot of room in your
    machine.  It would be nice to do something about this.  Unfortunately,
    simply omitting all the sequence functions takes away valuable basic
    functionality such as MEMQ.  Perhaps the subset could leave out some of
    the keywords, like :test and :test-not and :from-end.
[Again, these are simple if you're willing to do everything with ELT and
FUNCALL and are not going for tenseness.  It is checking for 53 special
cases that blow things up.  If you don't have them in, people will write
DO's and their code will balloon.]

    Hash tables are not strictly necessary, although the system itself
    are likely to want to use some kind of hash tables somewhere,
    maybe not the user-visible ones.
[Again, if you want tiny but slow, an A-list can do anything a
hash-table can.]

    Maybe some of the defstruct options could be omitted, though I don't
    think that getting rid of defstruct entirely would be acceptable.

    Some of the make-xxx-stream functions are unnecessary.

    Some of the hairy reader syntax is not strictly necessary.  The circular
    structure stuff and load-time evaluation are the main candidates.

    The stuff to allow manipulation of readtables is not strictly necessary,
    or could be partially restricted.

    Some of the hairy format options could be omitted.  I won't go into
    detail on this.

    Some of the hairy OPEN options could go, although I'd hate to be the one
    to decide which options are the non-critical ones.  Also some of the
    file operations (rename, delete, attribute manipulation) could go.
[All of the above sounds OK.]

    The debugging tools might be optional although probably they just
    get autoloaded anyway.
[For an educational system on cheap machines, you don't skimp here.  For
a delivery vehicle, you don't need these.]

∂18-Aug-83  1349	@MIT-MC:MOON@SCRC-TENEX 	subsetting
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83  13:49:26 PDT
Date: Thursday, 18 August 1983  16:40-EDT
From: MOON at SCRC-TENEX
To:   common-lisp at sail
Subject: subsetting

One last comment.  Inexpensive machines with ~ 1 megabyte main memory,
~ 40-80 megabyte disk, and VAX-class processors will be here sooner
than we think.  They may be limited by software and marketing more than
by technology.  So maybe by the time a subset was defined there wouldn't
be much demand for it.

∂18-Aug-83  1352	@MIT-MC:benson@SCRC-TENEX 	What to do next   
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83  10:06:04 PDT
Date: Thursday, 18 August 1983  11:54-EDT
From: dlw at SCRC-TENEX, benson at SCRC-TENEX
Subject: What to do next
To:   fahlman at cmuc
Cc:   common-lisp at su-ai


Scott, I appreciated your summary of pending issues in Common Lisp, and
I certainly think we should proceed to work on these things.  However, I
think that the "next things to do", after we get out the initial real
Common Lisp manual, are:

(1) Create a Common Lisp Virtual Machine specification, and gather a
body of public domain Lisp code which, when loaded into a proto-Lisp
that meets the spec, produces a complete Common Lisp interpreter that
meets the full language spec.  (This doesn't address the portable
compiler problem.)

(2) Establish an official Common Lisp subset, suitable for
implementation on 16-bit microcomputers such as the 68000 and the 8088.
I understand that Gabriel is interested in 68000 implementations, and I
am trying to interest Bob Rorscharch (who implemented IQLISP, which is
an IBM PC implementation of a UCILISP subset) in converting his product
into a Common Lisp implementation.

There are a lot of problems with subsetting.  You can't leave out
multiple values, beacuse several primitives return multiple values and
you don't want to omit all of these primitives (and you don't want to
discourage the addition of new primitives that return multiple values,
in future versions of Common Lisp).  You can't leave out packages, at
least not entirely, because keywords are essential to many functions.
And many things, if removed, would have to be replaced by something
significantly less clean.  We'd ideally like to remove things that (a)
can be removed without creating the need for an unclean simpler
substitute, and (b) aren't used by the rest of the system.  In other
words, we have to find modular chunks to break off.  And, of course,
any problem that works in the subset has to work and do exactly the
same thing in full Common Lisp, unless the program has some error
(in the "it is an error" sense).  The decision as to what goes
in and what goes out should be made in light of the fact that
an implementation might be heavily into "autoloading".

Complex numbers can easily be omitted.

The requirement for all the floating point precisions can be
omitted.  Of course, Common Lisp is flexiable in this regard anyway.

Rational numbers could be left out.  They aren't hard, per se, but
they're just another thing to do.  The "/" function on two integers
would have to signal an error.

Packages could be trimmed down to only be a feature that supplies
keywords; most of the package system might be removable.

Lexical scoping might possibly be removable.  You could remove support
for LABELS, FLET, and MACROLET.  You can't remove internal functions
entirely (i.e. MAPCAR of a lambda-expression can't be removed) but they
might have some restrictions on them.

Adjustable arrays could be removed.  Fill pointers could go too,
although it's not clear that it's worth it.  In the extreme, you could
only have simple arrays.  You could even remove multi-D arrays
entirely, or only 1-D and 2-D.

Several functions look like they might be big, and aren't really
required.  Some candidates: COERCE, TYPE-OF, the hard version
of DEFSETF (whatever you call it), LOOP, 

TYPEP and SUBTYPEP are hard to do, but it's hard to see how
to get rid of the typing system!  SUBTYPEP itself might go.

Multiple values would be a great thing to get rid of in the subset, but
there are the Common Lisp primitives that use multiple values.  Perhaps
we should add new primitives that return these second values only, for
the benefit of the subset, or something.

Catch, throw, and unwind-protect could be removed, although they're
sure hard to live without.

Lots of numeric stuff is non-critical:  GCD, LCM, CONJUGATE, the
exponentials and trascendentals, rationalize, byte manipulation, random
numbers.

The sequence functions are a lot of work and take a lot of room in your
machine.  It would be nice to do something about this.  Unfortunately,
simply omitting all the sequence functions takes away valuable basic
functionality such as MEMQ.  Perhaps the subset could leave out some of
the keywords, like :test and :test-not and :from-end.

Hash tables are not strictly necessary, although the system itself
are likely to want to use some kind of hash tables somewhere,
maybe not the user-visible ones.

Maybe some of the defstruct options could be omitted, though I don't
think that getting rid of defstruct entirely would be acceptable.

Some of the make-xxx-stream functions are unnecessary.

Some of the hairy reader syntax is not strictly necessary.  The circular
structure stuff and load-time evaluation are the main candidates.

The stuff to allow manipulation of readtables is not strictly necessary,
or could be partially restricted.

Some of the hairy format options could be omitted.  I won't go into
detail on this.

Some of the hairy OPEN options could go, although I'd hate to be the one
to decide which options are the non-critical ones.  Also some of the
file operations (rename, delete, attribute manipulation) could go.

The debugging tools might be optional although probably they just
get autoloaded anyway.