I even had my own proposal 5 years ago for improving that!
> That's right, but I would go one step further and have F(irst) and R(est), with obvious composition as follows: (using kruhft's examples from another thread)
> (ff x) == (caar x) == (car (car x))
> (rrf x) == (cddar x) == (cdr (cdr (car x)))
> I would argue that it's worth sacrificing the 'f' and 'r' symbols for such a common construct.> …
> Yes, I realize I'm 55 years late to the party.
https://news.ycombinator.com/item?id=13259344
Now we only need to implement both changes at the same time! :-P
Only when the tree structure conforms to certain conventions and intent of representing a list is the car "first" and the cdr "rest".
So of course those names are fine for nested lists: (ff '((a b c) d)): the "first of the first". But in, say, an assoc list ((a . 3)) 3 is not the "rest" of anything; it's the value of the key a.
The proposed functions go with the first and rest functions, rather than replace the cddr ones.
Now let's talk about something else: the order. In caddr, the order is just a condensation of the nested application of (car (cdr (cdr ...))), in the same order: it's easy to convert between the two, both actually and mentally. However, in left to right threading syntax, it's backwards:
(flow value car car cdr (+ 1))
corresponds to (+ 1 (cdr (car (car value))))
so it condenses like (flow value cdaar (+ 1))
You can see someone wanting a variant which has the letters in the opposite order.With f and r functions, you can do:
(flow value f f r (+ 1))
which is almost the backwards "ffr" you might want.Who is that for? Dummies who get it backwards? Oh, look, you're releasing in your destructor and acquiring in the destructor. Did you forget your CADR?