perm filename CLSUBS.MSG[COM,LSP]1 blob sn#772839 filedate 1984-10-27 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