Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!odi!valens!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp subsets - are there any?
Message-ID: <398@odi.ODI.COM>
Date: 23 Jul 89 22:30:04 GMT
References: <30255@cornell.UUCP>
Sender: news@odi.com
Reply-To: dlw@odi.com
Lines: 37
In-reply-to: houpt@svax.cs.cornell.edu's message of 23 Jul 89 18:07:58 GMT

In article <30255@cornell.UUCP> houpt@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.