Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!odi!valens!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp subsets - are there any?
Message-ID: <400@odi.ODI.COM>
Date: 25 Jul 89 23:50:28 GMT
References: <30255@cornell.UUCP> <398@odi.ODI.COM> <2234@wasatch.utah.edu> <12848@well.UUCP>
Sender: news@odi.com
Reply-To: dlw@odi.com
Lines: 33
In-reply-to: nagle@well.UUCP's message of 24 Jul 89 15:19:00 GMT

In article <12848@well.UUCP> nagle@well.UUCP (John Nagle) writes:

	A Common Lisp system that simply implements "Common Lisp, the Language"
   isn't all that big.  Look at KCL.  

True.

				      Common Lisp systems become unwieldy as
   people throw in an editor, an inspector, a debugger, a window manager, and
   put them all in the same address 

Yes, the usual Lisp tool strategy is designed for large address spaces.
That's why PDP-10's were ditched and Lisp machines were invented.  These
days, modern conventional workstations have huge address spaces.

				    and name space 

No.  That's what packages are for.

						   as the user's program,
   along with the compiler.  Having done so, they then find that switching
   from one tool to another leaves vast amounts of garbage around, so 
   garbage collection becomes slow.  

That all depends on whether you write the tools in such a way that
they generate a lot of garbage, and how good your GC is.  If your Lisp
suffers from an insufficiently-efficient GC, you can write Lisp code
in such a way that it doesn't generate much garbage.  Most real-world
systems do a combination of both things: improve the GC and code
things to do less allocation or manual deallocation (e.g.
"resources").  That tuning is necessary does not mean the whole
concept is wrong; just about every good large software system requires
and benefits from tuning, whether in Lisp or in C.