Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!decvax!tektronix!reed!bart
From: bart@reed.UUCP (Bart Massey)
Newsgroups: comp.lang.lisp
Subject: Re: Importance of REPLACA, REPLACD, and the like?
Message-ID: <6601@reed.UUCP>
Date: Mon, 13-Jul-87 14:19:35 EDT
Article-I.D.: reed.6601
Posted: Mon Jul 13 14:19:35 1987
Date-Received: Wed, 15-Jul-87 01:55:45 EDT
References: <22@citcom.UUCP> <13278@topaz.rutgers.edu>
Reply-To: bart@reed.UUCP (Bart Massey)
Organization: Reed College, Portland OR
Lines: 59

In article <13278@topaz.rutgers.edu> gaynor@topaz.rutgers.edu (Silver) writes:
> > Is it possible to solve serious programming applications with LISP
> > without using replacement operators?  To put it another way, could a
> > list be implemented in any other way than as a chain of cons nodes?
> > This is a novice type question, so please don't reply publicly.
> 
> Not nearly so novice as you think.  Any thoughts on alternative
> structures/paradigms?

At Reed college we are currently doing almost all of our lisp
programming in an in-house dialect which supports neither destructive
list functions nor dotted pairs.  The internal form of lists is a
lispval car, and a pure-pointer cdr.  This greatly increases the
efficiency of the language, effectively making the replacement
operations and dotted-pair notation unnecessary (all we could ever
figure out that they were good for was efficiency anyway, and whatever
they gained in efficiency they lost in verifiability and
understandability.)

We have written several substantial applications in this lisp (e.g. a
UNIX shell, an LL(1) parse table generator) and never once missed the
features we left behind.

In case anyone is interested, the following major changes in the
language were also implemented, and have proven useful:

- Elimination of eq: Using a properly written version of equal, eq is
the first thing to happen anyhow, and we've never encountered a
situation where knowing that two lists were non-eq is "good enough".

- Functions as first class lispvals:  We eliminated the seperate
"function cell" in favor of scheme-style first class functions.  Seems
like a big win in every way.

- No intrinsic property lists:  There's a fairly efficient prop-list
emulation package, but we use it mostly for porting outside code, and
encourage programmers to avoid prop-lists.  It's always trivial, when
writing the code, to work around them, and it's yet another extra cell
per atom to be avoided, in addition to often making the code more confusing.


All of the above-mentioned features have been uniformly good
experiences for us.  Benefits we expected and received include:

- It's really much harder to write twisty, unreadable lisp code, so we
can generally read other folks' code easier.

- It's much easier to teach the language to novices, as things are
much more uniform and the internals are much better hidden.

- It's much easier to redesign the internals, as they don't need to
affect the externals very much.


We will probably distribute this lisp soon.  Your comments and
suggestions are welcome.

					Bart Massey
					UUCP: ..tektronix!reed!bart