Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.eiffel Subject: Re: Reference Semantics Message-ID: <6495@goanna.cs.rmit.oz.au> Date: 25 Jun 91 07:22:43 GMT Article-I.D.: goanna.6495 References: <133169@tut.cis.ohio-state.edu> <135300@tut.cis.ohio-state.edu> <1991Jun24.221402.14058@cis.ohio-state.edu> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 57 In article <1991Jun24.221402.14058@cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: > In article <6375@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. > O'Keefe) writes: > > Just because it doesn't LOOK like a pointer doesn't mean that it > > doesn't ACT like a pointer and have the PROBLEMS of a pointer. > > There seems to be a [meta?]semantic problem here. Reference variables > and integers have very different [programming] semantics. No meta-semantic problem, just a reading problem. > If two reference variables R and S point to the same object, then > performing an operation on R will cause a visible (and all too often > unwanted) change to S. This is simply false. Indeed, the change is visible *through* S precisely because S *hasn't* changed. If you are trying to argue by example that failure to distinguish between references and the things referred to is a source of confusion and mistakes, we're agreed. For concreteness, let's use a C example: char shared_object = 'a'; char *R = shared_object; char *S = shared_object; *R = 'b'; Now, after this assignment through R, how (be precise) has S itself changed? It is still the same bit pattern that it was before. It is still equal to R. It still refers to the very same object that it did before the assignment through R took place. R hasn't changed, and neither has S. *R has changed, and so therefore has *S, but R is not *R and *S is not S. In exactly the same way, I can do char shared_objects[300] = { ..., 'a', ... }; int R = 17; int S = 17; shared_objects[R] = 'b'; Now, after this assignment using R, neither R nor S has changed. But although there wasn't any assignment of the form shared_objects[S], shared_objects[S] has in fact changed. > If two integer variables I and J both happen to have the value 17, then > using I to update an entry in an array A has no effect on J. The > semantics of this situation are of the simple, everyday sort. > From a complexity of semantics perspective, the analogy just doesn't > hold. But I have just illustrated in tedious detail above the kindergarten- level fact that the analogy _does_ hold. And in fact in the language Euclid the compiler was supposed to generate verification conditions for pointers in exactly the same way that it was to generate verification conditions for arrays. But, I hear you exclaim, pointers can point anywhere, while uses of arrays make it plain which array can be affected! Euclid pointers pointed into "zones", and two pointers to the same type of element could only refer to the same object if they pointed into the same zone, so "pointing anywhere" is not an essential aspect of pointer-nature. -- I agree with Jim Giles about many of the deficiencies of present UNIX.