From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!rochester!kodak!uupsi!sunic!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.ada
Subject: Re: Reference vs. copy semantics in passing parameters
Message-ID: <2635@enea.se>
Date: 17 Feb 91 18:54:17 GMT
References: <2725@sparko.gwu.edu> <jls.666659373@yoda> <2742@sparko.gwu.edu>
Organization: Enea Data AB, Sweden
List-Id: <comp.lang.ada>

Also sprach Micheal Feldman (mfeldman@seas.gwu.edu):
>Jim Showalter (jls@yoda.Rational.COM) writes:
>>In C++, you can declare not only the pointer constant but the pointed
>>to construct constant as well. This allows passing by reference in a
>>read-only manner, which is NOT possible in Ada at present.
>
>Well now I'm curious. Given that only scalars and small structures are
>usually passed by copy, why would you want to guarantee reference
>passing for read-only parameters in such a kludgy way? Ada provides you
>with everything you need:

Don't get confused by terminology. Forget about passing mechanisms.
Remember data abstraction.

If you have a routine which takes a pointer parameter as IN, you
are guaranteed that the *pointer* don't change, but the object
pointed to may be completely altered. For instance look at:

   PROCEDURE P(X : IN ADT);

Am I as a caller that Do_something from this signature guaranteed
that P does not change X? Answer: No. If I look in the package
specification I find that ADT is limited private. Only if I cheat
and sneak into the private part and find that ADT is declared as
a pointer-less type I know that X won't change. If there is a pointer,
and often that's all an ADT is, P may change X just as much as it
wants. Remember that as a user, I may perceive X as a completely
static object.

The practical implication is on the side of the ADT implementor. He
may choose to define ADT as a pointer in order to be able to defer
the record definition to the package body, and thereby reducing
recompilation impact in case he adds or removes a field. The cost
of this is that he loses compiler control of inadvertent changes
to IN parameters, and we're back on the Pascal level.

>PS: It seems to me that Ada9x could clarify the issue by simply requiring
>that structured parameters be passed by reference (instead of the Ada83
>rule that it's implementation-dependent). Since a program whose behavior
>depends upon the method of passing is - by definition of the LRM -
>erroneous, the only programs that would break would be erroneous ones,
>which Ada9x says it doesn't care about. So the clarification would be
>upward compatible. Ada9x-ers: what would be the objections?

Ada should not bind the implementors in order to make ugly
programming unambiguous. Rather I think Ada is going too far
when requiring a certain implementation in some situations.
The IN, OUT and IN OUT modes are a beautiful invention with
exception of the problems mentioned above.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"...I cannot understand someone saying 'Rush makes pretty good music, 
but they ARE commercial'." -- William J Bouma