Re: Dynamic accessibility

["Randy Brukardt" <randy@rrsoftware.com>]

<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