time to finalize srfi-17? Per Bothner (13 Jun 2000 21:26 UTC)
time to finalize srfi-17? Shriram Krishnamurthi (13 Jun 2000 21:48 UTC)
Re: time to finalize srfi-17? Per Bothner (13 Jun 2000 23:04 UTC)
Re: time to finalize srfi-17? David Rush (14 Jun 2000 07:27 UTC)
Re: time to finalize srfi-17? Per Bothner (14 Jun 2000 16:09 UTC)
Re: time to finalize srfi-17? David Rush (14 Jun 2000 17:24 UTC)
Re: time to finalize srfi-17? Per Bothner (14 Jun 2000 17:43 UTC)

Re: time to finalize srfi-17? David Rush 14 Jun 2000 17:23 UTC

Per Bothner <xxxxxx@bothner.com> writes:
> David Rush <xxxxxx@bellsouth.net> writes:
> > And your arguments are at best partial approximations to the actual
> > semantics of set!.
> This fastidiousness is all very well, but it is not Scheme.  Only
> lexical-set! can be claimed to "make changes in the bindings of its
> continuation", whereas global-set! "makes global changes in a data
> structure".

And neither are lexical-set! nor global-set! part of at least five
Schemes, and they are certainly not R5RS. What's your point?

> > set! is more like a function
> > call, structure updates are simple assignments.
> Well, that is certainly an unusual view-point, as it is
> backwards from how Scheme is normally presented.

Yep. I posted to c.l.s a while ago asking about this, and got a
thunderous silence for a response. Basically, I tried thinking about
what the CPS-form of set! should look like (as none of the literature
I've seen so far has covered that particular bit of the CPS
transformation). I'm sure I got it wrong somewhere, but in the absence
of correction, it certainly seems like set! corresponds to a multiple
argument function being tail-called on an apropriately-mangled version
of the source context.

If I ever get time and money enough to do a Piled Higher and Deeper
degree, I might even be able to prove it.

> > But you seem to be missing objection class 3: set! is not an
> > assignment operator (although it can be implemented as one).
> If the term "assignment operator" has any meaning at all, then
> clearly set! is an assignment operator.

I will concede that, under the 'robot duck'[1] criterion, set! is
effectively an assignment operator, but the question I've asked is
'Must set! be an assignment operator?' It turns out there the answer
is 'probably not'. Matthias has an implementation based entirely on
textual substitution. I've tried to approach the question via CPS.

Of course this begs the question of definition. I consider an
assignment operator to involve an update to the store. If I can define
set! without reference to the store then it's not an assignment
operator. Hence my interest in the CPS-transform of set!. I may have
gotten it wrong, but I would still like to know the answer.

> I'm not the one trying to change the meaning of commonly used
> terminology.

No, you're just introducing extremely non-local constructs into a
language which works pretty hard to maintain locality. I didn't like
SRFI-17 before I got into all of this semantic detail. I like it less
now that I have (a little) understanding. Nevertheless, it's still
yours to approve, so go ahead. Changing the name to setf! (SET! via
Function) would still be a better idea, so at least you're not
encouraging implementors into a specific implementation of set!

david rush
[1] - If it walks like a duck, talks like a duck, and smells like a
      duck, its probably a duck.
    - but if its a robot duck then it's merely anatidae-compatible