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