
The Origin of CAR and CDR in Lisp (2005) - tosh
http://www.iwriteiam.nl/HaCAR_CDR.html
======
ZenoArrow
To cut to the chase and save reading though all the unnecessary speculation,
this is the relevant part of this article...

>"The 704 family (704, 709, 7090) had "Address" and "Decrement" fields that
were 15 bits long in some of the looping instructions. There were also special
load and store instructions that moved these 15-bit addresses between memory
and the index regiseters ( 3 on the 704, 7 on the others )

We had devised a representation for list structure that took advantage of
these instructions.

Because of an unfortunate temporary lapse of inspiration, we couldn't think of
any other names for the 2 pointers in a list node than "address" and
"decrement", so we called the functions CAR for "Contents of Address of
Register" and CDR for "Contents of Decrement of Register".

After several months and giving a few classes in LISP, we realized that
"first" and "rest" were better names, and we (John McCarthy, I and some of the
rest of the AI Project) tried to get people to use them instead.

Alas, it was too late! We couldn't make it stick at all. So we have CAR and
CDR."

~~~
_0ffh
Well, after all we've always used CAR and CDR! If it was good enough then, why
shouldn't it be good enough now?

Also, the proposed new keywords were on average 50% longer. Just too much
typing! With FST and RST they would have stood a chance. HD and TL would have
been clear winners!

~~~
tspiteri
And fst and rst allow for composition too:

    
    
        caar -> ffst
        cddar -> rrfst

~~~
qwertyuiop924
But that doesn't look as nice.

~~~
Turing_Machine
It would need to have a pronunciation convention before it could catch on.

[https://people.eecs.berkeley.edu/~bh/pronounce.scm](https://people.eecs.berkeley.edu/~bh/pronounce.scm)

~~~
bhrgunatha
Instead of (f)irst/(r)est we could use (h)ead _or_ (f)irst and (r)est. Then
the pronunciation is just exactly as it is spelled -
[https://www.youtube.com/watch?v=spefM2OjKp4](https://www.youtube.com/watch?v=spefM2OjKp4)

------
dang
One interesting thing here is that the attempt to get people to stop using the
'bad' names car and cdr is only a few months younger than car and cdr
themselves. This is analogous to the plan (which lasted a few years) to
replace s-expressions with m-expressions. In both cases the 'bad' construct
stuck around because it's easier to program with.

~~~
lmm
I think people might still start new s-expression based languages, whereas any
respectable new language will use head/tail rather than car/cdr.

~~~
dang
I don't know about respectable, but I prefer car/cdr even in a new Lisp. In
addition to the composability of the notation, which others have cited,
there's the clear lexical symmetry between the two; their compactness, which
adds value when writing and reading concise programs; and how easy they are to
say out loud. There's something also about their precision: when you say 'car'
or 'cdr' in a Lisp context it's immediately clear that there's a linked list
at hand and you're talking about it.

The main disadvantage is that they're words with no immediate connection to
their meaning, but that's true of many words we're all familiar with. It
really only costs anything in the learning stage—which admittedly is a
critically important stage. But I think it's fair for a programming language
to use specialized idioms for a small number of their most fundamental
constructs.

~~~
bluefox
CAR and CDR are also good names because they are part of the Lisp tradition.
Also due to this tradition, they have a clear meaning in the context of Lisp.
If the "new Lisp" keeps conses (and some may argue that if it doesn't, it
shouldn't really fall under "a Lisp"...), perhaps it should also keep these
names.

------
kruhft
car and cdr may not be the best names, but they allowed for composition, like:

    
    
        (caar x) == (car (car x))
        (cddar x) == (cdr (cdr (car (x)))
    

Something which you can't do with first and rest. This has (AFAIK) always been
one of the arguments for car and cdr.

~~~
s_kilk
I dunno, as a latecomer lisp-enthusiast, that cadaddaaadr stuff seems heinous
to me.

~~~
kruhft
It's not pretty, but it has a consistency to it that includes a lot of compact
information in a digestable manner. It takes no longer to decode what the
instructions say, but it saves a lot of time parsing, for the human reader of
the program.

Compare:

    
    
        (caadar x) => (car (car (car (cdr (car x)))))
    

Saves parens too.

~~~
kbp
You can make it even easier on human readers by defining accessors (even if
they're just wrappers over car/cdr) and giving them meaningful names. Asking
for the car of the car of the cdr of the car of an ad-hoc data structure is
pretty hostile toward human readers regardless of whether or not you use
caadar.

~~~
junke
That's why you actually won't find many instances of such patterns in
practice. Either you refactor to have structures/classes, or you define your
own accessors. Besides, if you are using CL, FIRST, SECOND, THIRD, ... ,
TENTH, NTH and REST are defined by the spec
([http://clhs.lisp.se/Body/f_firstc.htm](http://clhs.lisp.se/Body/f_firstc.htm)).

------
topkekz
I prefer car/cdr over first/rest since a list is an implicit type and cdr/car
are actually operating on pairs that are not necessary part of a list.

