Newsgroups: comp.lang.eiffel
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!seal.cis.ohio-state.edu!ogden
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Subject: Re: Reference Semantics
Message-ID: <1991Jun26.232040.1503@cis.ohio-state.edu>
Sender: news@cis.ohio-state.edu (NETnews        )
Organization: The Ohio State University, Department of Computer and Information Science
References: <135300@tut.cis.ohio-state.edu> <1991Jun24.221402.14058@cis.ohio-state.edu> <6495@goanna.cs.rmit.oz.au>
Date: Wed, 26 Jun 1991 23:20:40 GMT
Lines: 57

In article <6495@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 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.

Where we seem to disagree is on the English language meaning (metasemantics)
of the phrase `different programming semantics'. What I understand the
phrase to mean is that the formal operational or denotational semantics
for the two constructs are different.

  [C pointer and array examples deleted for brevity]
  ...
>> From a complexity of semantics perspective, the analogy [between 
>>objects with references and arrays with integer indices] 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.  ...

Now just based on the fact that objects with references are `a source of
confusion and mistakes', while integers and arrays are not, we would expect
that the two constructs are semantically distinct. And so they are.

Semantically, an integer variable J is assigned a value of mathematical
type Z (the integer type); an array variable A is assigned a value of
type (Z -> Item), where Item is the type of the entries in A.

For program objects of underlying type Item with reference semantics,
things are a bit more complicated. We need to establish a set Item_Ref
of reference objects and a function Item_of: (Item_Ref -> Item). A reference
variable R can then be assigned a value of type Item_Ref. A reassignment
R := S just changes the Item_Ref assigned to R, but not the underlying
Item_of function. On the other hand, a basic class operation on R will
typically change the Item_of function, so that Item_of( R ) has the
appropriate new value. Clearly, arrays and reference objects have different
semantics.

Now you might observe that an array A of Items is just a function from
a set (Z) into the Item set, while a type Item with reference semantics is
likewise just function from a set (Item_Ref) into the same Item set, and
wonder what the big difference is which accounts for the confusion and
mistakes by programmers. The answer is that the Item_Ref set and Item_of
function are both implicit and hidden in the language notation. You
can't modify an entry in array A without explicitly referencing A in
the program text, so it won't be any surprise when subsequent uses
establish that A has changed. This certainly isn't true of the hidden
Item_of function.