CAR = Contents of Address Register, corresponding to the head element of a list.
CDR = Contents of Decrement Register, corresponding to a pointer to the "rest" of a list, i.e. to a machine word containing the next link in the list.
This is hinted at in the paper by this:
> "Each computer word of a list in addition to containing a datum also contains the address of the word containing the next element of the list. 0 for the address of the next element indicates the last element. If one element of an expression is a subexpression the word corresponding to this element contains the address of the word containing the first element of the subexpression. In the IBM 704 or 709 whose 36 bit word is divided (for the convenient use of certain machine instructions) into two 15 bit parts (address and decrement) and two 3 bit parts (prefix and tag) lists are represented by storing in the decrement part of a word the address (in our system actually the complement of the address) of the next word or the list."
The choice of names is rather implementation-specific (and if memory serves, this may have been a choice by the person who coded the original LISP interpreter, not McCarthy himself.) But the mapping of the abstract concept of a linked list to a usable machine representation, built into the core of a programming language, was impressive. FORTRAN and COBOL had nothing like this.
Vague recollection, could be wrong -- in J, you can apply a "rank" to verbs, which determines how the verb applies to its arguments. So for example, if we define that average verb:
In this instance I believe the "_ is just giving back 4r3p1 = 4.18879 for each of the arguments handed to the rest of the verb. This is one of those things that is second nature once you internalize J, but so so foreign until you do.
> PRs are emails to your team and to your future self.
Indeed! I've found many point on this discussion answered by the linux kernel idea of mailing lists where a change is discussed then approved, often with feedback acknowledged
Don't try to write "good" go and it becomes easy too.
I would rather see clearly defined, readable, documented code that isnt optimal... than good code lacking any of those traits.
And good code often isnt clearly defined, it often isn't reader friendly and it often lacks documentation (this bit is fixable but ends up needing a lot more of it).
... However I'm not sure how much I trust it. It says that 5x7 was "the usual PDP-6/10 convention" and was called "five-seven ASCII", but I can't find the phrase "five-seven ASCII" anywhere on Google except for posts quoting that Wikipedia page. It cites two references, neither of which contain the phrase "five-seven ascii".
Though one of the references (RFC 114, for FTP) corroborates that PDP-10 could use 5x7:
[...] For example, if a
PDP-10 receives data types A, A1, AE, or A7, it can store the
ASCII characters five to a word (DEC-packed ASCII). If the
datatype is A8 or A9, it would store the characters four to a
word. Sixbit characters would be stored six to a word.
To me, it seems like 5x7 was one of multiple conventions you could store character data in a PDP-10 (and probably other 36-bit machines), and Wikipedia hallucinated that the name for this convention is "five-seven ASCII". (For niche topics like this, I sometimes see authors just stating their own personal terminology for things as a fact; be sure to check sources!).
I like challenges like this. First, the edit that introduced the "five-seven ascii" is [1] (2010) by Pete142 with the explanation "add a name for the PDP-6/10 character-packing convention". The user Pete142 cites his web page www.pwilson.net that no longer serves his content. Sure it can be accessed with archive.org and from the resume the earliest year mentioned is 1986 ( MS-DOS/ASM/C drivers Technical Leader: ...). I suspect that he himself might have use the term when working and probably this jargon word/phrase didn't survive to a reliable book/research.
You do better with a search for "PDP-10 packed ascii". In point of fact the PDP-10 had explicit instructions for managing strings of 7-bit ascii characters like this.
That was true at the system level on ITS, file and command names were all 6 bit. But six bits doesn't leave space for important code points (like "lower case") needed for text processing. More practical stuff on PDP-6/10 and pre-360 IBM played other tricks.
