Me:
>Furthermore, there will be an opportunity (which I believe Per pointed out
>in his original SRFI) to right a wrong where there is an asymmetry in R5RS
>where there are a lot of getters without corresponding setters (most
>notably, cxxr..cxxxxr). These can all be added to the language (library,
>whatever) via the set! extension

David Rush:
>Don't be daft. At least in the case of the composed list accessors
>(c[ad]...r) having corresponding setters is just asking for
>trouble. As it is I *rarely* use anything deeper than cadr (and even
>that only when I'm being sloppy) because I can't validate the access
>any deeper without some serious work.

Okay, this is really a side issue, but I feel compelled to defend myself
here. I wasn't advocating in my parenthetical that cxxr...cxxxxxr are good
to use in maintainable production code. (I don't advocate using even car or
cdr in maintainable production code unless that code is actually dealing
with a (conceptual) pair/list.) However, given that R5RS has them already,
you might as well provide corresponding setters, and make the life of a
prototyper a little easier. I know I've personally written set-cadr! at
least three times and set-caddr! at least once for various projects.

Again, the point wasn't the goodness or badness of the particular setters
in question but rather the goodness or badness of the current asymmetry
between getters and setters. I'm in favor of symmetry.

And just to be painfully clear: If and when there's a decent and
widely-deployed record system (e.g. SRFI-9 if it became truly standard),
I'd drop *all* of cxxr..cxxxxxr (and their setter companions) from the
language, since at that point there probably wouldn't be any
arguably-useful use for them.

-dan