C*R

[Guy.Steele at CMU-10A]

Besides the lack of data abstraction, there is the problem that long
C*R strings are hard to parse.  Is CADDADDDADR the same as CADDADDADDR?
Even when I occasionally use long C*R strings in my code, I break them
up into meaningful units just so you can follow them.  My general rule
is that all A's must immediately follow a C, except in the two cases
CAAR and CADAR.  Thus the above two names would come out as
(CADDR (CADDDR (CADR X))) and (CADDR (CADDR (CADDR X))).  It is easily
seen that I only use twelve of the thirty C*R functions of up to four letters:
CAR CDR CADR CAAR CADAR CADDR CADDDR CDDR CDDDR CDDDDR
and not only can I not count in my head, I forgot that I sometimes
use CDAR as well.  The point is that each of these names is just within
the limit of a "chunk size" that can be grasped immediatel(for me).

But if I have to write such messes in more than two places, it's time to
drag out DEFSTRUCT or the equivalent.

So while it might seem inelegant to have an arbitrary cutoff on C*R
strings at four A/D's (and it surely is inelegant), nevertheless it
is a good limit to impose on oneself anyway for reasons of readability.
When I was young and naive I put this "feature" into my IBM 1130 LISP
(this was in 1971), and then discovered that I never ever wanted to use it.
--Guy