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.
First my disclaimer: I am not steeped in Scheme lore, but I have been hacking in many different environments and languages for fifteen years or so. I hated this SRFI. But I figured that it could be harmlessly left alone and that, if it passed on to final status, actual usage would ultimately determine its value a few years down the road. But then: DB> == Dan Bornstein wrote on 24 Jan 2000: DB> I am *strongly* in favor of generalized set! and pretty much agree with Per DB> as to the reasons why, although I don't quite agree with the proposed DB> underlying mechanism. I must say that this was one of my major turn-offs for his proposal, as well. DB> I'm much more in favor of reifying locations DB> (lvalues, cells, whatever you want to call them) and, for that matter, DB> environments (although that's probably better suited to be in a separate DB> SRFI), and expecting the usual optimizations to elide their usage as DB> appropriate. That seems much more in line with "Scheme thinking" to me than DB> rewriting calls with extra arguments. This is a very interesting idea, and as Per has said that it was his original intent, congratulate you on your perceptiveness. I was rather too lost in the details of Per's proposal to see it. As such, I would *at least* suggest that the SRFI be rewritten to make this clearer. DB> Just to reiterate what Per has said: There is a nice economy of concepts DB> when you get to collapse, on one axis, all of these into one concept of DB> "modifying a location": DB> set! set-car! set-cdr! string-set! vector-set! DB> and on another axis, all of these pairs into a concept each of what DB> location they denote: DB> car set-car! DB> cdr set-cdr! DB> string-ref string-set! DB> vector-ref vector-set! Yes. And I must admit that in these terms I find this proposal somewhat seductive. However, Per's analogy with the C `&' operator makes very clear how big this issue is. SRFI-17 is tinkering with fundamental language semantics. How does adding *explicit* pointer types and the accompanying pointer-aliasing problems interact with the compiled Schemes? Or how they interact with the garbage collector? Now, I am not totally opposed to this idea, but I rather like the way that things currently work in Scheme. The proposed model of L-values actually seems remarkably close to SML's ref type (which I like), but with an important difference: In Scheme (AFAIU) *all* names are bound to values of ref type, whereas in SML only those names which are explicitly declared to be so are. Scheme includes some magic so that all values of ref type are automatically dereferenced, *except* in the case of SET!. SET-CAR! & friends don't even enter into the picture, they are simply operations on opaque types following the usual Scheme rules. An equivalence: Scheme: (let ((foo 4)) (fact foo)) \ + both of which return 24 SML: let foo = 4 in fact foo / but they do it very differently. To execute the same (machine level) actions in SML as in Scheme: SML: let foo = ref 4 in fact !foo which also returns 24, but has implications for the store. So in Per's proposal (not the SRFI) Per> (define pa (location a)) has the SML type (scheme-object ref ref) or, in a coarser language, scheme_object**. I am having a bit of a hard time coming up with a way to express my misgivings about this construct. I think it boils down to the fact that Scheme *already* has this functionality, *if* you are willing to accept opaque types as a fundamental fact of life. In my *engineering* experience, I have found opaque types to be a universally good idea. This is so much the case that even when I am programming in straight C, I still use abstract setters in preference to direct mutation of structs; it is *much* easier to ensure data structure integrity with opaque types. Essentially, this proposal is to make Scheme more like C. Whether that is a good thing is debatable. I would like to be able to really do systems-level programming directly in Scheme. Having reified locations (and thus the ability to access hardware-level addresses) would be an advance toward that end. OTOH, the compiler, type, and engineering safety implications all worry me. Gripping hand is that this might really be an r6rs issue. Prototyping it here in the SRFI process may be a good thing, but I would certainly like to see some of the deeper implementation issues addressed. In other business: DB> Furthermore, there will be an opportunity (which I believe Per pointed out DB> in his original SRFI) to right a wrong where there is an asymmetry in R5RS DB> where there are a lot of getters without corresponding setters (most DB> notably, cxxr..cxxxxr). These can all be added to the language (library, DB> whatever) via the set! extension 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. DB> and simultaneously *simplify* the mental DB> model of the language that a programmer maintains. I think I showed previously that this (Well, Per's first-class locations) does not simplify the mental model of the language. It in fact complicates it, adding pointer aliasing, and ref ref types being bound to identifiers. Whether this comlication is useful or desirable is another matter. david rush -- I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat