From: Charles (Chuck) Houpt
Subject: Common Lisp subsets - are there any?
Date:
Message-ID: <30255@cornell.UUCP>
I recently re-read the article "A Critique of Common Lisp" by Rodney
Brooks and Richard Gabriel in the Proc. 1984 ACM Sym. on Lisp and
Functional Programming. The article discusses many of the flaws in
Common Lisp.
The major flaw is that Common Lisp is simply too big and complex to be
implemented efficiently on stock hardware. Brooks and Gabriel
suggest the creation of a standard subset of Common Lisp. The subset
would be easy to implement on stock hardware.
Does there exist a standard or de facto subset of Common Lisp?
-Chuck Houpt
·····@svax.cs.cornell.edu
From: Dan Weinreb
Subject: Re: Common Lisp subsets - are there any?
Date:
Message-ID: <398@odi.ODI.COM>
In article <·····@cornell.UUCP> ·····@svax.cs.cornell.edu (Charles (Chuck) Houpt) writes:
The major flaw is that Common Lisp is simply too big and complex to be
implemented efficiently on stock hardware.
This claim has yet to be backed up by solid reasoning and
demonstration. Most of the "size" and "complexity" of Common Lisp
arises from Common Lisp's inclusion of a large, extensive library of
useful utility routines.
It would be easy to make a subset by simply omitting many of those
routines. Then programmers would have to reconstruct those routines
themselves. When we designed Common Lisp, we didn't think that would
be an improvement.
In general, the philosophy of Common Lisp is the reusable code idea:
instead of making every programmer do the same standard job over and
over, provide a wide range of generally-useful building blocks for
everyone. The idea is to remove effort from the programmer by
shifting effort to the language implementor. Yes, it's hard to
implement Common Lisp, but that's because it does so much for its
users.
Does there exist a standard or de facto subset of Common Lisp?
No and no, last time I looked. Perhaps someone who is current with
the X3J13 meetings can report as to whether there is still a "subset"
committee, and whether they have made progress. Initial discussions
showed that there are great differences of opinion about which
features should be retained, and which removed, in a subset.
For example, the subset used within Gnu Emacs is pretty good for
writing editor extensions. But quite a few general-purpose Lisp users
would be severely handicapped by its lack of floating point number
support. It has been suggested that there's no single subset that's
particularly compelling, but that there might be various rather
specialized subsets for various purposes that would make sense.
From: Sandra J Loosemore
Subject: Re: Common Lisp subsets - are there any?
Date:
Message-ID: <2234@wasatch.utah.edu>
In article <···@odi.ODI.COM> ···@odi.com writes:
> Does there exist a standard or de facto subset of Common Lisp?
>
>No and no, last time I looked. Perhaps someone who is current with
>the X3J13 meetings can report as to whether there is still a "subset"
>committee, and whether they have made progress. Initial discussions
>showed that there are great differences of opinion about which
>features should be retained, and which removed, in a subset.
My impression is that subsets are a dead issue within X3J13. I
personally thought it would have been nice to have one or more
standard subsets specified, but realistically I didn't see much chance
that we would ever agree on any particular subset. Besides many
people being opposed to the whole idea of subsets, there didn't seem
to be any agreement among those who did want subsets on how to go
about dividing up the language.
There has been some talk that ISO might eventually standardize a
subset of ANSI Common Lisp, or divide it into kernel and library
parts, but I certainly don't expect that to happen anytime soon (if
ever).
-Sandra Loosemore (······@cs.utah.edu)
From: John Nagle
Subject: Re: Common Lisp subsets - are there any?
Date:
Message-ID: <12848@well.UUCP>
A Common Lisp system that simply implements "Common Lisp, the Language"
isn't all that big. Look at KCL. 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 and name space 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. Then they have to make garbage
collection much more complicated so that tool-switching isn't so painful.
Then they find that the new garbage-collection strategy has to be
integrated with the virtual memory system to prevent thrashing.
Eventually it can all be made to work, but was it worth it?
John Nagle
From: Dan Weinreb
Subject: Re: Common Lisp subsets - are there any?
Date:
Message-ID: <400@odi.ODI.COM>
In article <·····@well.UUCP> ·····@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.
In article <·····@well.UUCP> ·····@well.UUCP (John Nagle) writes:
A Common Lisp system that simply implements "Common Lisp, the Language"
isn't all that big. Look at KCL. Common Lisp systems become
unwieldy
....
Eventually it can all be made to work, but was it worth it?
John Nagle
Having spent a significant amount of time implementing a highly
integrated Common Lisp system the only sane answer I can give is yes.
I strongly believe that there IS more to a Common Lisp system than
just Common Lisp. This probably goes for C++, ... also. First, a
rich, window based, integrated toolset directly increases programmer
productivity because the Lisp system is easier to use, due to a good
user interface, sophisticated source level debugging tools, powerful
editing facilities etc. Secondly, the programming tools are usually
built using some kind of toolkit with a well defined interface. This
toolkit provides amongst other things a set of user interface widgets
that relieve the applications programmer (AP) from the chore of having
to implement his own user interface components, such as a text editor,
menus, buttons, grapher, etc. Ok, so the resulting Lisp system is
larger but for APs developing sophisticated and/or window based
applications it seems justifiable. Besides when runtime/delivery
images etc are available the size of the development environment
becomes less important.
Sophisticated garbage collection techniques benefit both application
programs and programming environments - no user of a Lisp system on a
small workstation likes waiting tens for seconds for a garbage
collection to complete while their system thrashes. There is no
need to integrate garbage collection with the virtual memory system;
very good performance can be obtained on standard platforms running
unmodified operating systems.
--
chris richardson
----------------
·····@harlqn.co.uk, ..!uunet!mcvax!harlqn.co.uk!chris
Harlequin Ltd, Barrington Hall, Barrington, Cambridge, CB2 5RG, England.
Phone: 0223 872522 (National), +44-223-872522 (International).