Re: Reference vs. copy semantics in passing parameters

[mfeldman@seas.gwu.edu (Michael Feldman)]

In article <jls.666837388@yoda> jls@yoda.Rational.COM (Jim Showalter) writes:
>Yes, but you miss my point (I think?). It is not modification of the
>POINTER we are trying to prevent. We are trying to prevent modification
>of what the pointer points to, and there is currently no way to insure
>this in Ada. A doofus can break the rules with impunity.
Hmmm.Are you implying that C++, or whatever, can guarantee that an entire
linked list could be kept safe from modification by making its head pointer
an IN parameter? Neat idea, but how on earth could it be implemented?

If you mean only the directly designated value, i.e. the node (say) that
the pointer points to but not the other nodes "down the line", I don't
really think you've accomplished very much.
>
>Why would it BE a pointer? Beats me, but these things do happen from time
>to time, and when they do it would be nice if the language made them safe.
Well, this is a matter of taste. It's impossible (or nearly, IMHO) to make
the language safe from people who insist on using side effects. The goal,
it seems to me, is to make it difficult to _accidentally_ do stupid things.
If people want to do them deliberately, they will find a way no matter how
safe we think we are building things.
>
>One gross thing that people do currently is give IN/OUT semantics to
>parameters on functions by passing a pointer and dereferencing it inside
>the function to modify what the pointer points to. There is no way to
>prevent this egregious behavior at present (note: many many people have
>also requested that 9x include IN/OUT's on functions, which would make
>the case for performing the trick just described even weaker).
A dumb idea, if you ask me. People are trying to make Ada behave like C.
If they try hard enough to subvert the safety that Ada provides, they will
find a way to succeed. Ada9x is looking at this issue (it's in the
requirements document, but I don't recall if it's a requirement or a study
topic); I hope they leave this as it is in Ada83.

As I recall, the argument for allowing IN/OUT's on functions is that
since nonlocal references are allowed on functions, allowing IN/OUT's  
is a clearer way of doing the same thing. There is a certain logic to
this, I must say. But if you encapsulate the function in a package, using
the nonlocal reference only to maintain state data, with the client unable
to muck with the state variable, then an IN/OUT parameter does _not_
accomplish the same thing, because it exposes the state variable to the client.

Mike Feldman