Re: CAR and CDR

[Dave Touretzky <Dave.Touretzky at CMU-10A>]

I was not kidding about CAR and CDR.  While I agree wholeheartedly that
FIRST and REST, HEAD and TAIL, etc., are awkard, and that short names
for the most basic primitives are essential for "natural" languages, I
also believe that these names should have some mnemonic properties.

I am planning to teach LISP to some novice programmers next fall.  These
are people who have probably never seen a computer before.  I think it
is going to be fairly embarassing to explain to them why they have to
say "CAR" and "CDR" instead of something more intuitive.  "Contents of
Address portion of Register" is not very mnemonic for someone who does
not know what an address or a register is.  These relics of the 7090 are
amusing bits of trivia for us hackers, but they aren't so amusing to
frustrated non-Lispers trying to develop an intuitive understanding of
a very foreign language.

With regard to composition of these nasty selectors into more obscure
forms, I have the following observation.  We either use composition to
select some top-level element further down the list, e.g.  CADR, CADDR,
CADDDR, or we use it to select some internal element, e.g.  CDDAADDAR.
Quick, tell me what CDDAADDAR means!  (I'm sure you can pronounce it,
but what does it mean???)

I suggest that top-level selection can be replaced with more intuitively
named primitives like 1ST, 2ND, 3RD, 4TH, 5TH, etc.  Note that these all
contain 3 letters, while the current scheme would use CADDDR (six letters)
for 4TH, and CAR of CDDDDR (7 letters plus an extra function nesting) for
5TH.

In the case of internal elements, we already know that it is better to
define macros for selecting named elements than to use obscure
composite selectors like CDDAADDAR.  The existence of a structure
package for MacLisp using named elements makes it reasonable to suggest
that the convention be used universally.  This leaves perhaps one or two
special cases, like CDAR or CAADR, that occur often enough to have
built-in names.  I'm sure people can think up something suitable.

We Lispers keep talking about the wonderfulness of an interpretive
program-development environment, and the non-Lispers are beginning to
listen.  Now I think it's time that we listen to some of what they've
been saying about fighting obscurity in languages and programs.