Re: Newbie Access Types

Re: Newbie Access Types

[Matthew Heaney]

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)

Newbie Access Types

[Ronald Ayoub]

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. 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.
Maybe I'm being picky but I like to learn things thoroughly.

Thanks.

Ron

Re: Newbie Access Types

[Nick Roberts]

You are correct about a formal out parameter of an access type being
initialised from the value of the actual, as per RM 6.4.5(13). I believe the
reason you suggest is or was the reason for this rule.

It has always seemed to me that an equally satisfactory rule (or allowable
option) would be for the formal to be initialised to null, especially when
Access_Check is in effect (or, if not, where it is known the hardware traps
an attempt to dereference a null access value, and this trap can be handled
as an exception).

However, it also seems to me that it could be quite cogently argued that
such an initialisation is folly, in that there is no reason why the
subprogram failing to set the value of the parameter (to something logically
sensible in the prevailing context) should not cause the program to come
crashing disastrously down anyway. (And the language allows worse things to
happen anyway, such as when an abort divides an operation to do with access
values.)

I would not, myself, subscribe to such an argument, since I (and, I imagine,
others) would hold that, in practice, there will be many situations where
such an initialisation will save a problem turning into a crisis.

I should imagine that the initialisation could be eliminated by an optimiser
under certain circumstances, but (as I'm sure Robert Dewar would be quick to
point out) it may well be that this optimisation would never be worthwhile
in practice (too complicated for the small benefit).

-------------------------------------
Nick Roberts
http://www.adapower.com/lab/adaos
-------------------------------------

Ronald Ayoub <rayoub@wam.umd.edu> wrote in message
news:7pe6tg$dqq$1@dailyplanet.wam.umd.edu...
| 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. 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.
| Maybe I'm being picky but I like to learn things thoroughly.

Re: Newbie Access Types

[Robert A Duff]

"Nick Roberts" <nickroberts@callnetuk.com> writes:

> However, it also seems to me that it could be quite cogently argued that
> such an initialisation is folly, in that there is no reason why the
> subprogram failing to set the value of the parameter (to something logically
> sensible in the prevailing context) should not cause the program to come
> crashing disastrously down anyway. (And the language allows worse things to
> happen anyway, such as when an abort divides an operation to do with access
> values.)

The fact that an obscure and rarely-used feature like abort is dangerous
(and we don't know how to design the language otherwise) is not a good
reason to make an every-day run-of-the-mill feature like parameter
passing also dangerous.

> I would not, myself, subscribe to such an argument,

Good.  :-)

>... since I (and, I imagine,
> others) would hold that, in practice, there will be many situations where
> such an initialisation will save a problem turning into a crisis.
> 
> I should imagine that the initialisation could be eliminated by an optimiser
> under certain circumstances, but (as I'm sure Robert Dewar would be quick to
> point out) it may well be that this optimisation would never be worthwhile
> in practice (too complicated for the small benefit).

The initialization of the parameter is done at the call site, whereas
the information needed to eliminate it is in the called procedure.
So doing such an optimization requires the compiler to know about
both places at once, which makes it harder.

> -------------------------------------
> Nick Roberts
> http://www.adapower.com/lab/adaos
> -------------------------------------
> 
> Ronald Ayoub <rayoub@wam.umd.edu> wrote in message
> news:7pe6tg$dqq$1@dailyplanet.wam.umd.edu...
> | 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. 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.
> | Maybe I'm being picky but I like to learn things thoroughly.

It was a design goal of Ada 83 that access values could never be
undefined (except via low-level chapter-13-ish features, and things like
abort).  Therefore, a parameter has to be initialized to *something*.
For an 'out' parameter, null could work, or the value of the actual
could work.

That Ada 83 design goal always seemed silly to me, because
"Some_Array(Some_Uninitialized_Integer) := 99;" can do just
as much damage as "Some_Uninitialized_Pointer.all.X := 99;".
If I were designing the language, there would be run-time checks
for uninitialized vars.  People who gripe about slowness would
be told to use pragma Suppress.

Note that the rules for uninit integers and whatnot changed in Ada 95.

Also, in Ada 95, we have anonymous access types (for parameters and
discriminants), and they have no null value, so it's not possible to
initialize such parameters to null.

- Bob

-- 
Change robert to bob to get my real email address.  Sorry.

Re: Newbie Access Types

[Matthew Heaney]

In article <wcc4shlgtdw.fsf@world.std.com> , Robert A Duff 
<bobduff@world.std.com>  wrote:

> Also, in Ada 95, we have anonymous access types (for parameters and
> discriminants), and they have no null value, so it's not possible to
> initialize such parameters to null.

One thing I would have liked for inclusion is subtypes for named access
types.  That way you could declare a subtype that excludes null:

  type T_Access_Base is access all T;

  subtype T_Access is T_Access_Base range not null;
  -- or some other syntax

It's occasionally necessary to have a parameter of a named access type, and
at the same type require that a non-null value be passed in.  It would be
nice to have the compiler do the check, that we now have to do manually.

--
Matt

It is impossible to feel great confidence in a negative theory which has
always rested its main support on the weak points of its opponent.

Joseph Needham, "A Mechanistic Criticism of Vitalism"