This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.
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