parameter passing

[Eric Marshall]

The LRM 6.2:6 says that access variables have to be
passed via copy-in. What benefit does this have for IN parameters?
How could a user detect if a compiler did not do this?

Thanks in advance.

Eric Marshall
System Development Corporation, a Burroughs Company
P.O. Box 517
Paoli, PA. 19301
(215) 648-7223

USENET: sdcrdcf!burdvax!eric
{sjuvax,ihnp4,akgua,cadre}psuvax1!burdvax!eric
ARPANET: PAYTON@BBNG

[Geoff Mendal]

The answer to this question can be found in Ichbiah's
"Ada Rationale" draft, which by the way, will be coming
out in published form "soon". (This word comes from
Ichbiah himself, speaking at a local SIGAda meeting
last Tuesday in Silicon Valley.) See section 8.2.2
of the "Ada Rationale". I'll summarize it here for
those who don't have a copy.

Consider the following procedure to delete an element from
a doubly linked list:

type Element;
type Ptr is access Element;
type Element is
record
Prev,
Succ : Ptr;
Data : some_type;
end record;
E : Ptr;
procedure Delete (P : in Ptr) is
begin
P.Succ.Pred := P.Pred;
P.Pred.Succ := P.Succ;
P.Succ := null;
P.Pred := null;
end;

A call to this procedure of the form

Delete (X);

will work regardless of the parameter passing mechanism. However,
consider now the call:

Delete (E.Pred);

where the linked list, before the call, has the state:

Element: A B C D E F

succ: B C D E F ...
pred: ... A B C D E

If the parameter passing mechanism is by copy, then the desired
effect is achieved, but pass-by-reference will not work (the list
ends up in a state of "chaos"). You can work out the details
yourself, or see Ichbiah's pictures.

The language designers chose to make pass-by-copy the rule to
eliminate problems such as the one above. Access types allow
the programmer to create and manage aliases. It was the view
of the language designers not to have parameter passing create
more aliases of which the programmer is unaware. Another
problem with pass-by-reference is in achieving the desired
semantics on distributed systems with multiple address spaces.

I'll let you ponder these ideas, and leave you with perhaps a
tangential question (the answer for which is similar to this
question):

Why, for mode out access type parameters, does Ada require
copy-in of the actual access value? Obviously the formal
cannot read the actual's value, so why require that it be
copied in? (somewhat of a trick question)

gom
-------

[Mats_Oh...@qzcom.mailnet]

This is of good case for arguing that Ada should have (had?)
procedures inside records, much the way SIMULA has.
If so, you could just code E.Delete (or E.Pred.Delete) with
no problems with parameters. It would also given Ada the
possibility to be more "functional". Consider e.g.
a system for matrix handling - a possibility to
code A:= B.Inverse.Transpose; would give much clearer
code than Transpose(A,Invert(B)) with parameters in out.
Something for Ada88 (90?)?

Mats_Ohlin_FOA2%QZCOM.MAILNET [@MULTICS.MIT.EDU]