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: <1991Jun24.221402.14058@cis.ohio-state.edu>
Sender: news@cis.ohio-state.edu (NETnews        )
Organization: The Ohio State University, Department of Computer and Information Science
References: <133169@tut.cis.ohio-state.edu> <135300@tut.cis.ohio-state.edu> <6375@goanna.cs.rmit.oz.au>
Date: Mon, 24 Jun 1991 22:14:02 GMT
Lines: 41

In article <6375@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A.
O'Keefe) writes:
   ....
>> There's not much sharing in a language like say FORTRAN or BASIC,
>> but I really doubt the functional language camp would claim such languages
>> either.
>There is a h**l of a lot of sharing in Fortran.  It's the major factor
>inhibiting the parallelisation that the scientific computing people would
>like to get.  Where is the sharing?  Destructive assignment to array
>elements.  Think
>	pointer : set of objects of base type :: integer : array
  ...
>    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. 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 a more complex semantic that the everyday semantic
in which all variables are independent. This complexity is apparent
in the difficulty of both programmer understanding as well as formal
proof rules.

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.

Now apart from COMMON, EQUIVALENCE and a few funny addressing games there
isn't much literal sharing in Fortran. So I wonder whether your remark about
` Destructive assignment to array elements' isn't really a comment upon the
sharing implicit in the high degree of coupling often found in Fortran
programs.

Certainly one can introduce alternative mechanisms (such as references
instead of pointers) which carry along some of the old problems you
were trying to eliminate. However, I don't see why arrays and integers
introduce the same problems as objects and references do.