c*r

[George J. Carrette <GJC at MIT-MC>]

You are making a rather strong statement when you say you would
probably boot the lisp machine down the stairs because it didn't
implement C*R. It depends on what you think is important to spend time
on fully and consistently supporting. General "language quality"
issues are much more important here than issues of "what is clear to
everyone who has ever heard of the language lisp."

For example, some people might not like the fact that in Franz 1.0E+99
reads in as 1.7014E+38 (i.e. no overflow checking in flonum
internalization), or that too many ")" gives the error message
"Readlist error, code 3" or that "'." gives the error message
"Readlist error, code 4" That may seem ok to somebody used to the
error messages provided by the Unix "C" compiler, but your average
hacker brought up in a Maclisp/ITS/Emacs=>Lispm environment just isn't
going to buy it.

There is a totally different perspective here, as evident from some of
your examples. If a user on a lispm, (or in Maclisp or Nil for that
matter), wanted to get at a deep subpart of a list structure during
interactive use they would not think of typing (cadddar x). Most
likely they would call upon an interactive structure walker, usually
called an "INSPECTOR," to get what they want in the minimum number of
key-strokes. Couple this with the fact that mininmum number of
keystrokes is not at all an issue inside program source-files,
and you can see why this C*R thing is not a bias of implementor against
user.

The most reasonable thing a lisp can do is probably to define only CAR and CDR,
and to insure that the compiler can optimize CAR/CDR compositions into calls
to the internal entry points to the usually defined set of C*R functions.

-gjc