Yeah, totally! It obviously should have read
def cdr(t): return t[1:]
:-)
— Gordo 
I detect signs of a previous lisp obsession.
Funny.. I’m just now starting to learn Lisp.
In my newbie-dom, Gordo seems right.
It depends on if you see car and cdr as operating on
lists or cells. The code is correct if you define:
def cons(a, b):
….return [a, b]
— Neil Schemenauer
I think you need more parentheses…
— Bruce
Mark,
Consider placing all the entries in your mobile edition on one page instead of making a list of links to really short one-entry pages. This would help those of us who look forward to reading you on the long, lonely train rides.
- Bo
— Bo
Gordo nailed it. If I remember my Scheme correctly, cdr should always return a list. The code never actually used cdr (although it did use car). I had just added cdr to be cute, and yesterday I realized (two years later) that I had been cute and wrong. Which is infinitely less satisfying than being cute and right.
— Mark
Bo, you should look into Plucker. Its default spidering depth of 2 will grab the entire mobile edition in one shot and wrap it up as a PDB for you. I’ve only used it under emulation, but several of my readers swear by it.
— Mark
OK, I just fixed the code, and added this:
def cadr(t): return t[1] # t[1:][0]
And it wasn’t just for the heck of it; I’m actually using it. So I’m not just putting the car(t) before the hors(e).
— Mark
Ack.
A core semantic of CAR, CDR is that they return
a *reference* to parts of the original list, not values.
car(t) and cdr(t) as defined return *copies* of first and last part of t. Which means that if I modify cdr(t), t is *not* modified. In Lisp, modifying (CDR t) would modify t.
— Phil
Phil: AFAIK, there’s no way to do that in Python.
— Mark