Dynamic accessibility

Dynamic accessibility

[sbelmont700]

Hi,

   Does anyone have any insight or historical perspective as to why it is that access parameters carry a dynamic lifetime along with them, whereas access discriminants do not?  I cannot think of a good reason why you would want to try and explicitly typecast an access parameter anyway, so it would seem easier on everyone had parameters been defined statically as discriminants are (i.e. lifetime as being declared inside the subprogram, so that it is checked by the compiler and forbids all attempts at typecasting).  
   
   On the other hand, if there is a good reason for doing it, then it would seem appropriate that one would need the same ability for access discriminants as well; i.e. carry along the dynamic lifetime so that someone could explicitly typecast it and save it somewhere else, exactly like an access parameter.
   
   Is there some sort of esoteric accessibility conundrum that requires the rules be like this, or is it a judgment call?  Was it just that the implementation of discriminants would be more costly than that of parameters?  Was the intention to provide a mechanism for both, so that a programmer could choose either way?  Or is it just that the lack of out parameters for functions and inability to dispatch on named access types required a backdoor in case an unlucky programmer was forced into an access parameter, but needed to get back the 'real' type of controlling operand?
   
   Thanks for any opinions, rants, or special secrets anyone might know.
   
-sb

Re: Dynamic accessibility

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:d2894d55-cb84-461c-8b82-da32093eda4b@googlegroups.com...

...
>   On the other hand, if there is a good reason for doing it, then it would 
> seem appropriate
> that one would need the same ability for access discriminants as well; 
> i.e. carry along
> the dynamic lifetime so that someone could explicitly typecast it and save 
> it somewhere else,
> exactly like an access parameter.

Well, this comes up from time-to-time -- it surely would be better if access 
discriminants had dynamic accessibility. However, the last time the idea was 
brought up, it was determined that dynamic accessibility would not work at 
all for discriminants. I forget the details, sorry, but my recollection was 
that it was impossible to implement.

BTW, there is concern that the dynamic accessibility of Ada 2005 and Ada 
2012 is in fact unimplementable as well. (AdaCore has not yet managed to do 
so.) The main problem is that we can't quite imagine what the alternative 
is, so it might have to be done in a very expensive manner.

Thus is is good that you can avoid dynamic accessibility by avoiding access 
parameters; use "aliased in out" in Ada 2012 instead and you get the *right* 
accessibility. ("in out" acts as local; "aliased in out" acts as if the 
accessibility is the point of the call -- this sounds hardly different, but 
it makes a huge difference in practice, as you cannot return the first but 
you can return the second.)

Note that dynamic accessibility is always a bad idea, in that it provides 
"tripping hazard" -- you might get an exception from a few calls, but not 
others. It's especially bad as calls from unit tests most likely will work 
(they're not nested) while ones in actual programs might (calls in nested 
subprograms are much more common).

I've become convinced that the entire idea of accessibility checks isn't 
worth the headaches (both in language definition and in practice). I 
virtually always use 'Unchecked_Access in my code, so the net effect is that 
I pay overhead for accessibility checks, but they never actually have any 
effect (positive or negative). 'Access will almost always fail on a 
parameter, so it doesn't even make sense to try to use it -- and it's very 
rare to have anything that is not encapsulated (the only time 'Access can be 
used).

                                     Randy.

Re: Dynamic accessibility

[sbelmont700]

On Thursday, June 21, 2012 2:43:06 PM UTC-4, Randy Brukardt wrote:
> Note that dynamic accessibility is always a bad idea, in that it provides 
> "tripping hazard" -- you might get an exception from a few calls, but not 
> others. It's especially bad as calls from unit tests most likely will work 
> (they're not nested) while ones in actual programs might (calls in nested 
> subprograms are much more common).

This was my real concern with the access parameter accessibility; the exception depends entirely on what the client passes in (though the rumor in Ada 2012 is that there exists a mechanism to compare accessibility levels, so that one might be able to conditionally typecast an access parameter...?).  It would seem a named type is preferable to an access parameter in any case in which assignment was necessary, especially in 2012 where there is not the 'in' parameter restriction for functions.  I'm sure there is an example I cannot think of, but what are the legitimate reasons someone would want to pass an access parameter and have occasion to cast it?  It seems backwards to provide a mechanism for ensuring assignment does not happen, and then implementing a workaround to allow it.

As always Mr. Brukardt, your responses are insightful and greatly appreciated; thank you for your continued help and support.

-sb

Re: Dynamic accessibility

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:192bee3d-c0d4-421d-b5f6-676bce2a38db@googlegroups.com...
>On Thursday, June 21, 2012 2:43:06 PM UTC-4, Randy Brukardt wrote:
>> Note that dynamic accessibility is always a bad idea, in that it provides
>> "tripping hazard" -- you might get an exception from a few calls, but not
>> others. It's especially bad as calls from unit tests most likely will 
>> work
>> (they're not nested) while ones in actual programs might (calls in nested
>> subprograms are much more common).
>
>This was my real concern with the access parameter accessibility; the 
>exception
> depends entirely on what the client passes in (though the rumor in Ada 
> 2012 is
> that there exists a mechanism to compare accessibility levels, so that one 
> might be
> able to conditionally typecast an access parameter...?).

Membership on access types in Ada 2012 includes the accessibility check. So 
you can write a precondition:

    Pre => Param in My_Access_Type

which will fail if the accessibility check would fail.

> It would seem a named type is preferable to an access parameter in any 
> case in which
> assignment was necessary, especially in 2012 where there is not the 'in' 
> parameter
> restriction for functions.  I'm sure there is an example I cannot think 
> of, but what
> are the legitimate reasons someone would want to pass an access parameter 
> and have
> occasion to cast it?  It seems backwards to provide a mechanism for 
> ensuring assignment
> does not happen, and then implementing a workaround to allow it.

I don't think there are any in Ada 2012. In Ada 95, you sometimes had to do 
that as a replacement for the missing "in out" parameter for a tagged 
object. Usually the trick was to "strip off" the accessibility check:

                   Param.all'Unchecked_Access

as you would have had to if the parameter was an "in out" parameter in a 
procedure. Note that "aliased" parameters help a bit here (they're 
guaranteed to live as long as the result of the function call, which is a 
bit longer than a "normal" parameter).

> As always Mr. Brukardt, your responses are insightful and greatly 
> appreciated; thank you
> for your continued help and support.

And thanks for the praise; it's always nice to hear it since most of the 
feedback anyone hears is about the mistakes they made. :-)

                                             Randy.


-sb 

Re: Dynamic accessibility

[sbelmont700]

On Friday, June 22, 2012 4:03:35 PM UTC-4, Randy Brukardt wrote:
> Note that "aliased" parameters help a bit here (they're 
> guaranteed to live as long as the result of the function call, which is a 
> bit longer than a "normal" parameter).

Since there is an active topic about it, what exactly is the distinction between explicitly aliased parameters for functions and those of procedures?  The way I read the LRM 6.1 (and from what I glean elsewhere), either a procedure or a function can have an E.A.P, and that your mention of 'function call' is assumed to mean 'subprogram call' in general.

However, the rules in 3.10.2 also vauge.  7/3 says "Other than for an explicitly aliased parameter...", so that parameter rule does not apply to EAPS of either functions or procedures.  13.3/3 deals specifically with functions, as does 19.2/3, and so nothing seems to explicitly apply to the EAP of a procedure.

Is there some other rule that applies by default, or is 'function' assumed to mean both (which I don't recall happening elsewher in the LRM, but I of course am not that familiar with it).

-sb

Re: Dynamic accessibility

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:ff9d9547-a61f-454e-8804-1e4f8018dac7@googlegroups.com...
On Friday, June 22, 2012 4:03:35 PM UTC-4, Randy Brukardt wrote:
>> Note that "aliased" parameters help a bit here (they're
>> guaranteed to live as long as the result of the function call, which is a
>> bit longer than a "normal" parameter).
>
>Since there is an active topic about it, what exactly is the distinction 
>between explicitly aliased
> parameters for functions and those of procedures?  The way I read the LRM 
> 6.1 (and from what
> I glean elsewhere), either a procedure or a function can have an E.A.P, 
> and that your mention
> of 'function call' is assumed to mean 'subprogram call' in general.

The accessibility of an explicitly aliased parameter for a procedure is the 
same as that for any other parameter of a procedure. The special case exists 
for the result of a function call, and thus it doesn't make any sense for it 
to apply to procedures (which have no result).

>However, the rules in 3.10.2 also vauge.

Oh no, you've looked into the "Heart of Darkness"! No one ever returns from 
there! :-)

>  7/3 says "Other than for an explicitly aliased parameter...", so that 
> parameter rule does
> not apply to EAPS of either functions or procedures.  13.3/3 deals 
> specifically with
> functions, as does 19.2/3, and so nothing seems to explicitly apply to the 
> EAP of a procedure.
>
> Is there some other rule that applies by default, or is 'function' assumed 
> to mean both
> (which I don't recall happening elsewher in the LRM, but I of course am 
> not that familiar with it).

It does look like a bug. But: No one understands 3.10.2, it literally takes 
hours to figure out any question in there (which is why it's nicknamed the 
"Heart of Darkness"). My recollection is that 3.10.2(7/3) is not formally 
needed and thus we used a sloppy wording. Moreover, that sentence is 
intended only to describe dynamic accessibility, which (hopefully) never 
will apply to an explicitly aliased paramter. Anyway, I'm not going to even 
think about spending the hours to figure out if you are right or if it is 
covered some other way.

In any case, 3.10.2 is one giant bug (plus it probably can't actually be 
implemented). So ask me in 2018 when we're getting the next revision of Ada 
underway. Hopefully by then this will all be gone. :-)

                                                      Randy.


-sb