Re: Access parameters and accessibility

["Michael B." <michaelb@example.com>]

On 12/16/14 22:34, sbelmont700@gmail.com wrote:
> I have a copy of the paper around, if you are that into things, but
> it's certainly not a casual read, nor does it really appeal to anyone
> except for the phony-tough or crazy-brave.


I would be happy if you could send me a copy. My mail address is:

mb_public <at> safe-mail <dot> net

I hope it will not cause too much damage to my mental health ;-)


> procedure Example6  is
>
>     type T is ...;
>
>     procedure P1(XP1 : access T) is
>        type A is access T;
>        Ptr: A := null;
>
>        procedure P2(XP2: access T) is
>        begin
>           Ptr := A(XP2);
>        end P2;
>
>     begin
>        P2(XP1);
>     end P1;
>
>     X : aliased T;
>
> begin
>     declare
>        Y : aliased T:
>      begin
>        declare
>           Z : aliased T;
>         begin
>           P1(X'Access);
>           P1(Y'Access);
>           P1(Z'Access);   -- pass or fail?
>         end;
>      end;
> end Example6;


> In this example, note that all the objects X, Y and Z are all longer
> lived than type A, which conceptually only exists for the duration
> that P1 is executing, so each conversion should pass.  But also note
> that the "depths" of the objects that P1 (and consequently, P2) is
> getting are becoming progressively "deeper" as each declarative block
> gets elaborated.  The question then becomes what "depths" should the
> conversion in P2 be checking?  If the normal block-nesting level was
> used (where X is 1, Y is 2, and Z is 3), then Z would become evaluated
> as "too deep", since A would be 2 and Z would be 3, and you would get
> an erroneous program error doing the conversion.
>
> So you can tweak things to say that in these special cases, you pass
> the *lower* of either the actual object depth or P1 itself.  So, in
> this case, now Z will pass the dynamic check since instead of getting
> the depth of Z, P2 gets the depth of P1 (since 1<3).  Now you can nest
> the declarative blocks a billion levels deep, and the proposed model
> still adheres to the LRM.

Ah, this is a nice example with a good explanation.
Thank you very much! Now I think I understand why this rule exists and 
how it is working.

> Again, it's important to stress that this is just one special case of
> one special part of just one possible implementation of one
> special-case language feature from twenty years ago, and that none of
> this should weigh heavily on your mind when learning or using Ada.

Does that mean that a compiler writer is allowed to implement this rule, 
but it is not strictly necessary?

I tried to compile and run your example. I replaced
"type T is ...;" by "type T is new Integer;"
and "type A is access T;" by "type A is access all T;"
to get it compiled (with Gnat 4.9 on Debian Jessie 8.0 amd64).
It runs but "P1(Z'Access);" raises Program_Error.

If I understand you correctly this is not a compiler bug and this 
optional rule was just not implemented in Gnat, right?

Regards,

Michael