Re: Newbie Access Types

["Matthew Heaney" <matthew_heaney@acm.org>]

In article <7pe6tg$dqq$1@dailyplanet.wam.umd.edu> , rayoub@wam.umd.edu 
(Ronald Ayoub) wrote:

> I have read that an access type parameter is always copied in even when
> the parameter is an out parameter and that this is so that the access type
> is not undefined which can cause problem.

Yes, access objects are always passed by copy.

> Could someone please elaborate on this? It is my thought that access types are
> initialized to null when not explicitly initialized so that an uncopied access
> type going into a function will only result in the formal parameter being
> initialized to null.

You definately want to read section 8.2.2 of the Ada83 Rationale.  It is
available online, but I have included that section here too.

Text format at adahome:
<http://www.adahome.com/LRM/83/Rationale/Text/ratl-c8.hlp>

HTML format at adaic:
<http://wuarchive.wustl.edu/languages/ada/ajpo/standards/83rat/html/
ratl-08-02.html>

Matt


(start of excerpt from Ada83 Rationale)
8.2.2 The Effect of Parameter Passing Mechanisms for Access Types


A difficulty  of a  different nature  arises for  parameter passing by
reference in  the  case  of  access  types.  Consider  for  example  a
procedure to delete a given element from a list (see section 6.3.6):

   type PLACE;
   type LIST is access PLACE;

   type PLACE is
     record
       SUCC     :  LIST;
       PRED     :  LIST;
       CONTENT  :  ITEM;
     end record;
   ...

   E :  LIST;
   procedure DELETE(L :  in LIST) is
   begin
     L.SUCC.PRED    :=  L.PRED;
     L.PRED.SUCC    :=  L.SUCC;
     L.SUCC     :=  null;
     L.PRED     :=  null;
   end;

This is  the conventional  way of  deleting an  element from a doubly-
linked list, and a call such as

   DELETE(X);

will work  regardless of  whether parameter  passing  is  achieved  by
reference or by copy. Consider however the procedure call

   DELETE(E.PRED);

where we assume the list to be in the following state before the call:

   place:          A     B     C     D     E     F
   successor:      B     C     D     E     F     ...
   predecessor:    ...   A     B     C     D     E

If parameter  passing is  by copy,  we achieve  the desired  effect of
deleting D (the predecessor of E) and we obtain the state

   place:          A     B     C     D     E     F
   successor:      B     C     E     null  F     ...
   predecessor:    ...   A     B     null  C     E

If parameter passing is by reference, then the formal parameter L will
refer to  the object  E.PRED.  The  first  assignment  will  have  the
expected effect  of establishing  E.PRED =  C. But this means that the
remaining statements  will operate  on C  (rather than D) and will not
achieve what  we want:  the second assignment will achieve B.SUCC = D;
and the  last two  assignments will  unlink C (rather than D), leaving
the list in a state of chaos:

   place:          A     B     C     D     E     F
   successor:      B     D     null  E     F     ...
   predecessor:    ...   A     null  C     C     E

One possible  reaction to  this example  is to consider that parameter
passing by  reference is  legitimate for access types, and that we are
just confronted  with an incorrect program. Our preferred viewpoint is
rather to  consider that  access types  are already unique in that the
programmer  is  permitted  explicitly  to  manipulate  references  and
construct aliases:  This  is  the  purpose  of  access  types,  and  a
programmer using  such types  is asserting  that  he  wishes  to  take
control of  all references  and aliases.  Accordingly,  the  parameter
passing should  not generate extra references and aliases of which the
programmer is  unaware; therefore,  all parameter  passing for  access
types should be by copy.

A final  problem with  parameter passing  by reference  is  that  this
mechanism will  be almost  impossible to  achieve (or  at least,  very
costly) on  distributed systems and whenever we deal with systems with
multiple address spaces.
(end of excerpt)