perm filename CLSUBS.MSG[COM,LSP]4 blob sn#787319 filedate 1985-02-17 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Introduction
C00005 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Subsets Subgroup.
In order to mail to this group, send to the address:

		CL-Subsets@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLSUBS.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Subsets-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Martin Griss		HP		griss.hplabs@csnet-relay (I hope)
Beau Sheil		Xerox		sheil@xerox
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Bob Kessler		Univ. of Utah	kessler@utah-20
Jay Lark		Teknowledge	lark@sumex
Carl Hewitt		MIT		hewitt-subsets@mc
Govind Deshpande	JPL		deshpande@jpl-vlsi.arpa
Gary Brown		DEC		gbrown@dec-marlboro
Eric Benson		Lucid		eb@su-ai
Jerry Barber		Gold Hill	jerryb@mc
Jed Marti		Rand		marti@rand-unix
Chris Schmidt		HPP		schmidt@sumex
Alice Hartley		BBN		hartley@bbn
Gordon Novak		Univ. of Texas	novak@utexas-20
Guy Steele		Tartan		steele@tl-20a
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Jim Meehan		Cognitive Sys.	meehan@yale

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂23-Sep-84  1624	RPG  	Introduction  
To:   cl-subsets@SU-AI.ARPA 
Welcome to the Common Lisp Subsets Subgroup.
In order to mail to this group, send to the address:

		CL-Subsets@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLSUBS.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Subsets-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Martin Griss		HP		griss.hplabs@csnet-relay (I hope)
Beau Sheil		Xerox		sheil@xerox
Dave Matthews		HP		matthews.hplabs@csnet-relay (I hope)
Bob Kessler		Univ. of Utah	kessler@utah-20
Jay Lark		Teknowledge	lark@sumex
Carl Hewitt		MIT		hewitt-subsets@mc
Govind Deshpande	JPL		deshpande@jpl-vlsi.arpa
Gary Brown		DEC		gbrown@dec-marlboro
Eric Benson		Lucid		eb@su-ai
Jerry Barber		Gold Hill	jerryb@mc
Jed Marti		Rand		marti@rand-unix
Chris Schmidt		HPP		schmidt@sumex
Alice Hartley		BBN		hartley@bbn
Gordon Novak		Univ. of Texas	novak@utexas-20
Guy Steele		Tartan		steele@tl-20a
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Jim Meehan		Cognitive Sys.	meehan@yale

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. 

∂27-Sep-84  0737	DUGGAN@UTAH-20.ARPA 	Please add me ty your group  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Sep 84  07:37:16 PDT
Date: Thu 27 Sep 84 08:39:01-MDT
From: Jerry Duggan <duggan@UTAH-20.ARPA>
Subject: Please add me ty your group
To: cl-object-oriented-programming@SU-AI.ARPA, cl-subsets@SU-AI.ARPA

I work with Bob Kessler at the University of Utah.

Jerry Duggan
-------

∂02-Oct-84  1316	RPG  	Chairman 
To:   cl-subsets@SU-AI.ARPA 
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.

The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show. 

Any takers?
			-rpg-

∂04-Oct-84  1435	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Chairman    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Oct 84  14:35:10 PDT
Received: from hplabs by csnet-relay.csnet id a011122; 4 Oct 84 17:26 EDT
Received: by HP-VENUS id AA16508; Wed, 3 Oct 84 06:38:31 pdt
Message-Id: <8410031338.AA16508@HP-VENUS>
Date: Wed 3 Oct 84 06:38:36-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Chairman
To: cl-subsets%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

I am willing to act as chairman/co-ordinator of the cl-subsets group.

I am currently exploring to what degree PSL (with appropriate
modifications) could be viewed as a CL subset. The version of PSL we
use at HP and some universities, has a significant CL compatibility
module (package system, pathnames, new reader, etc.).  With some
changes, and the installation of this module in the basic system, a
useful and fast "PSL strength" subset could be evolved. We are writing
a simple translator to aid the transition from "old" PSL to "new" PSL.

I will first submit an initial proposal to the PSL and Standard LISP
communities for discussion, and then share the revised versions and
comments with the rest of our working group.

Are there any other subset proposals/partial compatibility packages or
translators (from subset to subset) being "brewed" out there?

Martin Griss
-------

∂13-Oct-84  1447	RPG  	Chairman 
To:   cl-subsets@SU-AI.ARPA 

No one has been nominated as chairman of the Subsets subgroup.  I will
need either a volunteer or a nomination.  Please respond by October 24. At
the end of this month I want to see some ideas and proposals coming in on
this mailing list.

			-rpg-

∂17-Oct-84  1138	jrg@cmu-cs-spice.arpa 	Re: Chairman     
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  11:38:33 PDT
Date: Wednesday, 17 October 1984 11:53:23 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: Dick Gabriel <RPG@su-ai.arpa>
cc: cl-subsets@su-ai.arpa
Subject: Re: Chairman 
Message-ID: <1984.10.17.15.52.41.Joseph.Ginder@cmu-cs-spice.arpa>

I thought Martin Griss volunteered for this.  Did he not?

--Joe

∂17-Oct-84  1258	WHOLEY@CMU-CS-C.ARPA 	Chairman     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  12:57:51 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 17 Oct 84 15:52:39-EDT
Date: Wed, 17 Oct 1984  15:25 EDT
Message-ID: <WHOLEY.12056214685.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   cl-subsets@SU-AI.ARPA, Dick Gabriel <RPG@SU-AI.ARPA>
CC:   Joseph.Ginder@CMU-CS-SPICE.ARPA
Subject: Chairman 
In-reply-to: Msg of 17 Oct 1984  11:53-EDT from Joseph.Ginder at cmu-cs-spice.arpa

Joe's right.  The following is in the archives...
-------------------------------------------------------------------------------
    Date: Wed 3 Oct 84 06:38:36-PDT
    From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
    Subject: Chairman
    To: cl-subsets%su-ai.arpa@csnet-relay.arpa
    Cc: GRISS@hplabs.CSNET
    Source-Info:  From (or Sender) name not authenticated.

    I am willing to act as chairman/co-ordinator of the cl-subsets group.

    I am currently exploring to what degree PSL (with appropriate
    modifications) could be viewed as a CL subset. The version of PSL we
    use at HP and some universities, has a significant CL compatibility
    module (package system, pathnames, new reader, etc.).  With some
    changes, and the installation of this module in the basic system, a
    useful and fast "PSL strength" subset could be evolved. We are writing
    a simple translator to aid the transition from "old" PSL to "new" PSL.

    I will first submit an initial proposal to the PSL and Standard LISP
    communities for discussion, and then share the revised versions and
    comments with the rest of our working group.

    Are there any other subset proposals/partial compatibility packages or
    translators (from subset to subset) being "brewed" out there?

    Martin Griss
-------------------------------------------------------------------------------

∂17-Oct-84  1437	marti@randgr 	Re: Chairman    
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 17 Oct 84  14:37:29 PDT
Received: by randgr.ARPA; Wed, 17 Oct 84 14:09:40 pdt
From: Jed Marti <marti@randgr>
Message-Id: <8410172109.AA13976@randgr.ARPA>
Date: 17 Oct 84 14:09:35 PDT (Wed)
To: cl-subsets@su-ai
Subject: Re: Chairman

  Martin Griss has volunteered to act as chairman. If there needs to be a
formal nomination, then:

  I nominate Martin Griss to the job of acting chairman of the Common Lisp
Subset Committee.

Jed Marti

∂23-Oct-84  0632	jrg@cmu-cs-spice.arpa 	Re: Import and Export 
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 23 Oct 84  06:32:27 PDT
Date: Tuesday, 23 October 1984 09:25:42 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: cl-foreign-function-call@su-ai.arpa
cc: Tom Kaczmarek <KACZMAREK@usc-isif.arpa>, cl-subsets@su-ai.arpa
Subject: Re: Import and Export
Message-ID: <1984.10.23.12.56.30.Joseph.Ginder@cmu-cs-spice.arpa>

The CMU approach does allow other languages to make remote procedure calls
to Common Lisp.  I don't see that the issue of a minimal kernel is
particularly relevant to this.  For a foreign language to make calls on
Common Lisp does not require that the Lisp it is calling have some specific
functionality more than that it is there and can be called.  I certainly
don't expect to define what functions are avaliable in fortran libraries in
order to define a foreign funcall mechanism for Common Lisp; I don't see how
anything different is implied by the reverse situation.

When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC.  We then force a GC and save the new,
application-specific lisp core.  The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much.  I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.  

To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable?  We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).

--Joe

∂23-Oct-84  1515	Faunt%hp-thor.csnet@csnet-relay.arpa 	removal form list
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Oct 84  15:14:45 PDT
Received: from hplabs by csnet-relay.csnet id as05924; 23 Oct 84 17:56 EDT
Received: by HP-VENUS id AA29013; Tue, 23 Oct 84 13:33:08 pdt
Message-Id: <8410232033.AA29013@HP-VENUS>
Date: Tue 23 Oct 84 13:32:54-PDT
From: Doug <Faunt%hplabs.csnet@csnet-relay.arpa>
Subject: removal form list
To: cl-foreign-function-call%su-ai.arpa@csnet-relay.arpa, 
    cl-foreign-function-call-request%su-ai.arpa@csnet-relay.arpa, 
    cl-subsets%su-ai.arpa@csnet-relay.arpa, 
    cl-subsets-request%su-ai.arpa@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

Please remove dcm%hplabs@csnet-relay (or other equivalent address)
from your list, since this user doesn't exist here by that name,
and I'm tired of looking at the error messages.
-------

∂24-Oct-84  2036	WWHITE@SRI-KL.ARPA 	ad-hoc vs. planned subsets.   
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 24 Oct 84  20:36:47 PDT
Date: Wed 24 Oct 84 20:36:45-PDT
From: Bill <WWHITE@SRI-KL.ARPA>
Subject: ad-hoc vs. planned subsets.
To: cl-subsets@SU-AI.ARPA

When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC.  We then force a GC and save the new,
application-specific lisp core.  The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much.  I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.  

	The problem I see with this approach is that it is ad-hoc for
	each individual application. In all likelyhood, trying to combine
	programs developed separately, will produce less and less savings
	as the number of independent pieces goes up.

To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable?  We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).

	As I see it, the real reason for having well defined subsets is
	to increase the ability to intgrate work from many places successfully.

Bill White
-------

∂25-Oct-84  1043	marti@randgr 	Re: ad-hoc vs. planned subsets.
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 25 Oct 84  10:43:13 PDT
Received: by randgr.ARPA; Thu, 25 Oct 84 10:24:51 pdt
From: Jed Marti <marti@randgr>
Message-Id: <8410251724.AA11533@randgr.ARPA>
Date: 25 Oct 84 10:24:47 PDT (Thu)
To: cl-subsets@su-ai.ARPA
Cc: randgr!hearn@randgr
Subject: Re: ad-hoc vs. planned subsets.
In-Reply-To: Your message of Wed 24 Oct 84 20:36:45-PDT.
	     <8410250339.AA24984@rand-unix.ARPA>

Reasons for CL subsets:
   Another reason for subsets is the efficiency issue. Many of our application
programs are incredibly slow, to the point where the programs are being
rewritten in other languages. We spent two frustrating man years
converting a large Interlisp program into C (still not complete), the sole
reason being speed. I cannot justify the view that once an application is 
developed it should be converted into a static procedural language for 
efficiency. It is too costly and fosters the conviction that it should have 
been written in that medium in the first place. 

   I believe that a CL subset designed for speed is one that best serves 
embedded applications:
  1) a fast subset has fewer function calls to a smaller "library"
  2) it has a better chance of being CONSless than a system with hidden
     mechanisms
  3) the human interface can be isolated and extracted when not needed

Jed Marti   MARTI@RAND-UNIX

∂25-Oct-84  1534	WHOLEY@CMU-CS-C.ARPA 	ad-hoc vs. planned subsets. 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Oct 84  15:34:34 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 25 Oct 84 18:32:17-EDT
Date: Thu, 25 Oct 1984  18:32 EDT
Message-ID: <WHOLEY.12058345878.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Jed Marti <marti@RANDGR.ARPA>
Cc:   cl-subsets@SU-AI.ARPA, randgr!hearn@RANDGR.ARPA
Subject: ad-hoc vs. planned subsets.
In-reply-to: Msg of 25 Oct 1984  13:24-EDT from Jed Marti <marti at randgr>

One of the properties of Lisp is that it is VERY easy to write VERY inefficient
programs by choosing inappropriate data structures.  In older Lisps,
programmers were forced to use inappropriate data structures because things
like strings and vectors weren't around.  In addition to the good old Lisp
objects like symbols and conses, Common Lisp provides the data structures that
any other modern programming language provides, and a few useful high-level
data structures (such as hash tables).

A Lisp programmer must choose his data structures well, as must any programmer.
I think it is the burden of the implementor to prevent the "primitives" from
incuring any non-obvious runtime penalties.  I am an implementor, and I live
with that burden.

Given a good choice of data structures and algorithms, there is no real reason
why a Common Lisp program should run significantly slower than an equivalent
program written in a procedural language.  A case in point: The Spice Lisp text
editor, Hemlock, is significantly faster (doing things like text modification
and redisplay) than Oil, a text editor written in Pascal running on the same
machine -- a machine designed to run Pascal!  A lot of careful planning went
into Hemlock, and that planning payed off.  Hemlock does much more than Oil,
and is easily extensible because it is written in Lisp.

A member of our user community here wrote a number of useful CAD tools in Perq
Pascal, and has since been turned-on to Common Lisp.  He tells me that he can
develop programs many times quicker than he could in Pascal, and that the
performance lost by running them in Lisp instead of Pascal is less than 30%,
and sometimes 0%.

By limiting yourself to a subset with a "fast library" and few primitives, you
risk omitting a language feature that might be exactly right for some
application.  I'm willing to bet that a good Common Lisp implementation will
provide that feature more efficiently than a subset with that feature kludged
on as an afterthought.

I can't help thinking that a good deal of the "incredible" slowness of the
application programs you mentioned is due partly to the Interlisp language,
which has been known to provide features at the expense of efficiency -- a fine
thing if you've got a Dorado in your office.  Common Lisp claims heritage to
MacLisp, which put greater emphasis on efficiency.

I don't see how that fact that program X runs slowly in Lisp Y has anything to
do with making subsets of Lisp Z.  There are a lot of free variables there.

--Skef

∂27-Oct-84  2155	RPG  	Hello folks   
To:   cl-subsets@SU-AI.ARPA 

We now have a chairman of the subsets subgroup:  Martin Griss
of HP.  I think he will make an excellent chairman.  For your
information I am including the current members of the mailing list.

I will now let Martin take over responsibility for the discussion.

Dave Matthews		HP		"hpfclp!subsets%hplabs"@csnet-relay
Stan Shebs		Utah		shebs@utah-20
John Foderaro		Berkeley	jkf@ucbmike.arpa
Jerry Duggan		Univ of Utah	duggan@utah-20
Rod Brooks		MIT		"brooks%oz"@mc
Skef Wholey		CMU		Wholey@cmuc
Martin Griss		HP		griss.hplabs@csnet-relay 
Beau Sheil		Xerox		sheil@xerox
Bob Kessler		Univ. of Utah	kessler@utah-20
Bill White		Teknowledge	WWhite@sri-kl
Carl Hewitt		MIT		hewitt-subsets@mc
Govind Deshpande	JPL		deshpande@jpl-vlsi.arpa
Gary Brown		DEC		brown@dec-hudson
Eric Benson		Lucid		eb@su-ai
Jerry Barber		Gold Hill	jerryb@mc
Jed Marti		Rand		marti@rand-unix
Chris Schmidt		HPP		schmidt@sumex
Alice Hartley		BBN		hartley@bbn
Gordon Novak		Univ. of Texas	novak@utexas-20
Guy Steele		Tartan		steele@tl-20a
Joe Ginder		PERQ		Joseph.Ginder@cmu-cs-spice
Jim Meehan		Cognitive Sys.	meehan@yale
Jonl White		Xerox		jonl@xerox
Neal Feinberg		Symbolics	feinberg@scrc-stony-brook

∂12-Nov-84  0012	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Anybody there?   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Nov 84  00:11:58 PST
Received: from hplabs by csnet-relay.csnet id aa05319; 12 Nov 84 3:01 EST
Received: by HP-VENUS id AA17087; Sun, 11 Nov 84 09:19:58 pst
Message-Id: <8411111719.AA17087@HP-VENUS>
Date: Sun 11 Nov 84 09:15:59-PST
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Anybody there?
To: cl-subsets@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

This mailing list has been rather quiet the last few weeks, and I am
curious as to whether this reflects lack of interest, confusion as to
the next step, or distraction due to other things (e.g., elections,
cl-object-oriented-programming discussions, or ....).

We have a range of interests represented by people on this mailing
list, and I'd like to ask a few questions to get things rolling again.

1. What LISP or LISPs do you currently use?

2. Are you primarily a user or an implementor?

3. For those of you who are currently using non-common LISP's, such as
InterLISP, FranzLISP, PSL, etc, what is your plan for Common LISP?

	a. Ignore it
	b. Hand translate code to CL and switch to some implementation
	c. Develop a compatibility module for (a subset of) Common LISP
           in your LISP.
	d. Develop a translator for your LISP to Common LISP.
	e. Convert or extend your LISP to include a significant
           Common LISP subset.
	f. Begin an implementation of CL on your hardware.
	g. Other (?)

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?

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?

6. Some of the previous messages indicated that subsets were important for:
	
	a. Small (weak, "unreal", "obselete") machines
	b. Efficiency
	c. Ease of implementatation
	d. Interchange of code between workers who do not yet have a full CL
        e. Export subsets for canned applications; some people
           suggested a mechanical "disemboweling" would suffice,
           but others felt this would make combining applications difficult.
        f. Other (?)

   For what reasons might you consider a subset?

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

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


------------------------------------------------------------------------

I will send my own detailed responses to these questions shortly. I am
involved in examining CL subsetting issues with members of the
Standard LISP and PSL communities, here at Hewlett-Packard and
elsewhere.

Martin.

------------------------------------------------------------------------
-------

∂15-Nov-84  0537	brown@DEC-HUDSON 	Martin's questions    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 15 Nov 84  05:37:08 PST
Date: Thu, 15 Nov 84 08:37:23 EST
From: brown@DEC-HUDSON
Subject: Martin's questions
To: cl-subsets@su-ai


1. What LISP or LISPs do you currently use?
     Vax Lisp (Dec Common Lisp) on a 780.

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?
     Not currently, we hope that such packages find their way into
     the Yellow Pages (and might even be willing to help fund the
     generation of these packages).

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 currently have no plans to produce a subset of Common Lisp.
     We distinguish between a subset and a self-contained program written
     in Common Lisp which does not include all the language.  We are
     considering various mechanism which would allow a user to create
     an executable program which would require less resource (memory)
     than the full system.


7. Do you see a single subset as sufficient, or do you envision a family
   of subsets, appropriate for different reasons?
     I hope that, at least initially, one subset would be sufficient.
     Any implementation could say "we implement Subset Common Lisp 
     plus ratios."


8. Do you have a subset proposal ready to present to this group, or are
   you working on one?
     The main thing I think is that the subset should be a true subset;
     i.e. a program that is written purely in the subset is gaurenteed
     to work in an implementation of full language.  I believe this
     requires that the subset be lexically scoped.

-Gary Brown

∂15-Nov-84  0744	FAHLMAN@CMU-CS-C.ARPA 	Martin's questions    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Nov 84  07:44:35 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 15 Nov 84 10:43:26-EST
Date: Thu, 15 Nov 1984  10:43 EST
Message-ID: <FAHLMAN.12063776476.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-subsets@SU-AI.ARPA
Subject: Martin's questions


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

∂22-Nov-84  1650	marti@randgr 	Martins Questions    
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 22 Nov 84  16:50:20 PST
Received: by randgr.ARPA; Tue, 20 Nov 84 09:25:27 pst
From: Jed Marti <marti@randgr>
Message-Id: <8411201725.AA10594@randgr.ARPA>
Date: 20 Nov 84 09:25:20 PST (Tue)
To: cl-subsets@su-ai
Subject: Martins Questions

1. What LISP or LISPs do you currently use?
|   PSL mainly, some Franz and Interlisp.

2. Are you primarily a user or an implementor? 
|   User.

3. For those of you who are currently using non-common LISP's, such as
InterLISP, FranzLISP, PSL, etc, what is your plan for Common LISP?
|  For some projects where speed is of the essence, ignore it, unless
|  something is done about efficiency. We plan simulations with large
|  numbers of objects (like 10,000) and need the utmost in efficiency
|  out of our small machines (SUN's).

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?
|  We have a machanical translator which currently operates between
|  Interlisp, Franz Lisp, and PSL, as well as one under construction
|  from Standard Lisp '79 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?
| Implementors Hat: Efficiency and speed of compilation. Features which
| slow down the generated object code will be looked at very carefully. 
| Initially this includes the extendable arrays, and the four different
| floating point representations. A second criteria is frequency of use.
| The address space of the 8086, precludes a large library of seldom
| used functions. To this end we propose to make the complex and rational
| data structures part of a "load on call" library. 


6. For what reasons might you consider a subset?
|  Three reasons: small, weak, and obsolete machines such as the IBM PC, and
|  the Apple MacIntosh. Efficiency! Efficiency!

7. Do you see a single subset as sufficient, or do you envision a family
   of subsets, appropriate for different reasons?
|  Possibly two subsets: An efficient subset, and an educational subset
|  (maybe this should be a superset).

8. Do you have a subset proposal ready to present to this group, or are
   you working on one?
|  As part of the Standard Lisp user group, I have done some work in
|  identifying problems with Standard Lisp to Common Lisp translation.

Jed Marti  MARTI@RAND-UNIX

∂08-Dec-84  2156	REM  
To:   CL-SUBSETS@SU-AI.ARPA 
[In reply to Griss's set of questions for members to answer:]
We have a range of interests represented by people on this mailing
list, and I'd like to ask a few questions to get things rolling again.

1. What LISP or LISPs do you currently use?
[My favorite among those I've used is MacLISP at MIT-MC, but since Stanford
 no longer provides 1200-baud dialup access into the Arpanet I'm back at
 300 baud to MIT-MC and I haven't used it much lately. I'm actively using
 and developing PSL at IMSSS (Tenex) and PASC (VM/CMS). Long ago I used
 Stanford LISP 1.6 and UCI-LISP, but gave them up long ago.]

2. Are you primarily a user or an implementor?
[Both. LISP is my language of choice for any task it can handle if I'm
 on a machine that has it, although I occasionally have to write some
 utility program in SAIL if LISP is too inefficient (the SCAN function
 in SAIL is handy and very fast, I wish PSL had something like it) or if
 I just happen to know how to write a one-shot task quickly in SAIL but
 would have to do a lot of figuring to get it written in LISP. But for any
 largescale program I always write in LISP, so I'm a major LISP user.
 I write application software and general support utilities, but lately
 at IMSSS for pay I'm getting into implementation of the kernel.]

3. For those of you who are currently using non-common LISP's, such as
InterLISP, FranzLISP, PSL, etc, what is your plan for Common LISP?
[Wait until CL is available on a machine I have access to, then give it
 a try to see if it can do what I want at similar speed. If it takes twice
 as long to run a program in CL as in PSL, I'll stay with PSL, otherwise
 I'll probably try switching to CL. If I can get my hands on a translator
 that works, I'll use it, else I'll manually do it with EMACS macros and
 backwards-compatibility functions. (I already have such functions for
 supporting various MacLISP, Standard-LISP, and personal functions in
 terms of PSL primitives, such as ML-LET which is like LET in MacLISP
 with destructuring which I use all over the place. I wish CL had
 destructuring available. In any case I will keep programming in some
 form of LISP until something better comes along, which is unlikely.]

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?
[The mimimal subset should run on an Altair 8800a (8080 cpu) with 28k bytes
 of RAM. A little more reasonable subset should run on an IBM PC with the
 minimum memory configuration that starting computer users might already
 have bought. A really decent subset should run on a PDP-10 under Tenex.]

6. Some of the previous messages indicated that subsets were important for:
   For what reasons might you consider a subset?
[For running on small machines, and to simplify bootstrapping on a new machine.]

7. Do you see a single subset as sufficient, or do you envision a family
   of subsets, appropriate for different reasons?
[Mostly I see a heirarchy of subsets, from bare-minimum to whole ball of
 wax and can of worms, with possible branches like bare-minimum with
 floating point but not packages, or packages but not floating point, etc.]

8. Do you have a subset proposal ready to present to this group, or are
   you working on one?
[I have no formal proposal at this time, but a while back I went through a
 LISP manual identifying those functions which were absolutely essential to
 get any LISP running at all, versus those which had their uses but weren't
 essential in every program. I think fewer than a hundred functions were
 in the former category. If somebody is interested I can fish out my notes
 and send my DRASTIC-TEENSY-TINY-LISP subset proposal as a starting point
 for very-minimal subset discussions.]

∂08-Dec-84  2225	REM  
To:   CL-SUBSETS@SU-AI.ARPA 
From: brown@DEC-HUDSON
     The main thing I think is that the subset should be a true subset;
     i.e. a program that is written purely in the subset is gaurenteed
     to work in an implementation of full language.  I believe this
     requires that the subset be lexically scoped.
[I disagree with that conclusion. There are several ways that one LISP
 can be a subset of another: (1) it can be missing some of the functions,
 (2) it can be missing some of the datatypes, (3) some of the functions
 can know about and be able to handle fewer of the kinds of situations,
 be less flexible, have fewer options, (4) some of the overall mechanisms
 can be less capable.

These are mostly but not totally orthogonal. ACOSH and ASINH can be missing
 even if floating point and complex values are available, thus having
 the datatype doesn't imply all the functions to handle it are around.
 The converse, ASINH and ACOSH are available but they don't handle floating
 point, is probably impossible in CL. Thus they are orthogonal in one
 direction. Ratios might not be implemented, which would mean that READ
 would have to bomb out if it encountered the syntax for a ratio, and
 division of integers couldn't be implemented in all cases either. Thus
 there is some linkage between datatypes available and case that READ and
 / are equipped to handle. Finally, to rebut the assertion claimed above,
 a subset of CL might not have lexical closures implemented and might work
 correctly only on programs that have no undeclared free variables, it might
 even have no optional or rest arguments. A program written in this restricted
 subset would work fine in full blown CL, with identical semantics. Thus a
 subset needn't have lexical scoping. -- For the mathematicians, the null
 language that has no functions and no datatypes, is a subset of CL, and
 is an obvious counterexample to the claim that any subset of CL must have
 lexical scoping. But I think there could be reasonable non-null subsets that
 are easy to implement on small machines or to define in existing systems
 such as PSL, which don't have lexical scoping yet are true subsets.

I think we should be aware of the several dimensions of subsetting, some
 of which I listed above, and consider all those dimensions when defining
 a subset, not just what functions are defined. When we define a subset,
 we should clearly document what functions aren't there at all, what functions
 are implemented in lesser ways, what datatypes are missing, what features
 of general code writing are missing (implicit PROGNs, lexical closures, ...),
 any other differences. Alternately for really drastic subsets just say what
 the subset is and indicate explicitly in the rare cases when the fullblown
 version of some function is defined.  Anyone agree or disagree or amend?]

∂09-Dec-84  0803	FAHLMAN@CMU-CS-C.ARPA    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Dec 84  08:03:37 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 9 Dec 84 11:04:08-EST
Date: Sun, 9 Dec 1984  11:04 EST
Message-ID: <FAHLMAN.12070071698.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Robert Maas <REM@SU-AI.ARPA>
Cc:   CL-SUBSETS@SU-AI.ARPA
In-reply-to: Msg of 9 Dec 1984  01:25-EST from Robert Maas <REM at SU-AI.ARPA>


REM makes a useful point, I think: a dynamically scoped implementation
can be a "true subset" of Common Lisp as long as the cases where the
diference can be seen are not allowed (or are not used in portable
code).  This could be as simple as requiring Special declarations around
any variable used free.

Enumerating the ways in which one language can be a subset of another is
useful, but I think it's important to keep the definition of "true
subset" in mind: if you're writing code in a true subset of Common Lisp,
your code will run in any full implementation of Common Lisp without
modification.  One can also envision "near subsets" in which the code
has to be modified in order to run in Common Lisp, but in which the
modifications are straightforward and perhaps can be done automatically.

My suggestion to DARPA has been that they should not bless any
particular subset, but that where code from many different systems must
ultimately run together (as in some parts of the Strategic Computing
program) they simply require that the code ultimately produced must run
in any full implementation of Common Lisp.  Researchers would be free to
write in a full Common Lisp, any "true subset", or a "near subset" if
they are willing to periodically do that translation.  They could even
do their research in some very diferent Lisp and then hand-translate the
result, though that is obviously doing it the hard way.  This way we do
not penalize people working in full Common Lisp (that would be
counter-productive to the goal of moving toward Common Lisp as a
standard), while providing the maximum flexibility for people who are
working in other implementations.

The only reason I can see for blessing some particular subset is so that
people working in this subset can trade code among themselves, though
they could not in general run code written in unrestricted Common Lisp,
of which there will be an ever-increasing amount.  A very minimal
"interchange subset" that can easily be implemented on top of PSL,
Interlisp, Franz, and maybe T would be of some value, but only if it is
not TOO much more restricted than the intersection of any one of these
languages with full Common Lisp.  My guess is that whenever a full
Common Lisp appears on any family of machines, people will start using
that and stop using the interchange subset.

-- Scott

∂09-Dec-84  1255	RPG  
 ∂08-Dec-84  2104	REM  
To:   CL-SUBSETS-REQUEST    
Please put REM@IMSSS on the list. I don't think IMSSS is currently in
any name domain, or if it is I don't know what it would be, but mail
can be forwarded via SU-SCORE.ARPA by using this address from the
Arpanet:  REM%IMSSS@SCORE.ARPA  from SU-AI it's a little harder because @
is reserved as a command to read text from an indirect file, so you
have to say "REM%IMSSS"%SCORE from here.

I think Common LISP as defined has a plethoria of seldom-used functions
and defining a workable subset for tiny machines (8080/z80 with 2↑16
bytes of memory or less) and small machines (PDP-10 with 2↑18 36-bit words)
is necessary if this is to be a truly common implementation instead of
a snob language for those with 68000 or LISPM or VAX or IBM-4033
that won't run on any smaller machine.

∂17-Feb-85  1820	fkunze%ucbopal.CC@Berkeley 	Please add the following names to the subset list   
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 17 Feb 85  18:20:15 PST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41)
	id AA13429; Sun, 17 Feb 85 18:21:15 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
	by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1)
	id AA05206; Sun, 17 Feb 85 18:21:59 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.33)
	id AA03905; Sun, 17 Feb 85 18:21:44 pst
Date: Sun, 17 Feb 85 18:21:44 pst
From: fkunze%ucbopal.CC@Berkeley (Fritz Kunze)
Message-Id: <8502180221.AA03905@ucbopal.CC.Berkeley.ARPA>
To: CL-subsets@su-ai.ARPA
Subject: Please add the following names to the subset list

Fritz Kunze     fkunze%franz.uucp@ucbkim.arpa
John Foderaro   jkf%franz.uucp@ucbkim.arpa
Both people are from Franz Inc.
Thanks.
--Fritz Kunze