Re: Access parameters and accessibility

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

"Adam Beneschan" <adambeneschan@gmail.com> wrote in message 
news:eea29e4c-921a-467c-8007-80e80eda3507@googlegroups.com...
On Tuesday, December 16, 2014 11:46:59 AM UTC-8, Michael B. wrote:
...
>I'm sure Randy was being tongue-in-cheek when he said "get better 
>libraries".

Ahh, no.

...
>For one thing, you'd have to get better libraries than the libraries Ada 
>provides,
>because Ada defines some subprograms with anonymous access 
>parameters--namely
>Ada.Tags.Generic_Dispatching_Constructor, Ada.Execution_Time.Timers.Timer, 
>and >Read|Write_Exception_Occurrence in Ada.Exceptions. Also, the stream 
>attribute
>subprograms ('Read, 'Write, etc.) all have anonymous access parameters, and 
>you
>have to *write* a subprogram that has an anonymous access parameter in 
>order to
>use it as the stream subprogram for a type.  Quelle horreur!

Yup. With the exception of timers, all of the others stem directly from the 
mistake of using an anonymous access for streams. And *that* stems from the 
mistake of not allowing "in out" parameters for functions (as Input is a 
function).

Ergo, in Ada 2012 you would write those as "in out Root_Stream_Type'Class". 
And one should think of them as exactly that. (It's too late to fix this 
mistake, sadly.)

In the case of Timer, (a) no one ever uses this feature, and (b) I have no 
idea why this just isn't

type Timer (T : Ada.Task_Identification.Task_Id) is tagged limited private;

I have no idea who has an aliased Task_Id laying around anyway. That seems 
amazingly hard to use for no value whatsoever. I suspect it was something 
else originally and it never got changed sensibly.

>Anyway, I think you can avoid defining new subprograms that take anonymous 
>access
>parameters (except where needed for streams, or for 
>Generic_Dispatching_Constructor)
>and not add to the problem, but I don't see any value in avoiding existing 
>libraries.

Well, if you could tell a-priori if "access" was used as a stand-in for "in 
out", then it would be OK. In that case, the only use of the "access" is to 
dereference it.

But it if is actually used as an access type (with the access value being 
copied somewhere), then you have trouble (with random Program_Errors and a 
need to avoid passing local objects). It's possible in Ada 2012 to write a 
precondition for this case, but of course that's not required (and surely is 
not found in existing libraries), so the possibility doesn't help much.

Since you can't tell these cases apart (and the first is never necessary in 
Ada 2012 anyway, with the possible exception of foreign conventions), it's 
best to just avoid the feature. Especially as "access" is more expensive 
than "in out" because of the dynamic accessibility checking overhead (which 
exists regardless of whether it is ever used). Libraries should reflect this 
(moreso as Ada 2012 gets adopted more).

                                Randy.