Anonymous Access and Accessibility Levels

Anonymous Access and Accessibility Levels

[Jere]

I was trying to get a bit better at understanding how accessibility
levels work with respect to anonymous access types.  I have GNAT to
test out things, but I think I am running into various bugs, so I am
not seeing the exceptions or compilation errors I would expect.  It
could also be that I misunderstand the rules (They are difficult 
somewhat).

Take for example a library level package like so:

Library_Level.ads
***********************************

package Library_Level is

   type T is record
      Value : Integer := 0;
   end record;
   
   type T_Access is access all T;
   
   type R is record
      -- This has accessibility level the same as T_Access I think?
      The_T : access T := null;
   end record;
   
   -- The discriminant has accessibility level of whereever the D type
   -- is created I think?
   type D(The_T : access T) is null record;
   
   
   -- For testing later
   The_T : aliased T := (others => <>);
   The_R :         R := (others => <>);
   
   The_T_Access : T_Access := null;

end Library_Level;

***********************************

I think that R.The_T has a library level accessibility level?
I think that D.The_T has an accessibility level relative to where
an object of type D is declared?
I think that D.The_T cannot be copied once initialized (at least
I think I remember someone mentioning that on comp.lang.ada)?

However, when I run some basic tests, I don't get all the errors
or exceptions that I expect.

main.adb
************************************

with Ada.Text_IO;
with Library_Level;

procedure Main is
   
   The_T : aliased Library_Level.T;
   
   -- This fails to compile...Good!
   -- The_R : Library_Level.R := (The_T => The_T'Access);
   
   procedure Test_AA_1(The_T : aliased in out Library_Level.T) is
      The_R : Library_Level.R;
   begin
      -- This fails to compile...Good!
      -- The_R.The_T := The_T'Access;
      null;
   end Test_AA_1;
   
   function Test_AA_2
      (The_T : aliased in out Library_Level.T)
       return Library_Level.R
   is begin
      
      -- This compiles???  Shouldn't this fail the same way the
      -- commented line in Test_AA_1 fails?
      return (The_T => The_T'Access);  
   end Test_AA_2;
   
   procedure Test_AA_3(The_T : aliased in out Library_Level.T) is
      
      -- This compiles!  I think ok? Anonymous Access use accessibility
      -- level of this location?
      The_D : Library_Level.D := (The_T => The_T'Access);
      
   begin
      -- This compiles??  Should this fails since it copies a local
      -- access to a global access variable?  Are we even allowed to
      -- copy an access discriminant in the first place?
      Library_Level.The_T_Access := The_D.The_T; 
   end Test_AA_3;
   
   The_R : Library_Level.R;
   
begin
   Ada.Text_IO.Put_Line("Testing Anonymous Access");
   Test_AA_1(The_T);
   The_R := Test_AA_2(The_T);
   Test_AA_3(The_T);
   
   -- Second test of Test_AA_2 to see if a runtime exception occurs. This
   -- would be copying a local variable access into a library level access
   -- variable.
   Library_Level.The_R := Test_AA_2(The_T);
   Ada.Text_IO.Put_Line("No runtime exceptions...hmmm");
end Main;


************************************

Here Test_AA_1 does everything I expect.  However, it seems like
Test_AA_2 is able to circumvent the restriction by returning an
aggregate instead of assigning directly.  I don't know if an 
aggregate is treated differently or not though.

Test_AA_3 not only allows the copy of the local object access, but
also allows the discriminant to be copied.  

I realize it might be much to expect all of these to get caught at
compile time, but they don't trigger any runtime exceptions either.

Can someone go through and help me understand this better? In
particular:

1.  Are my assumptions about the accessibility levels of 
Library_Level.R.The_T and Library_Level.D.The_T correct?

2.  Is there a GNAT bug(s) associated with Test_AA_2 and Test_AA_3
or do I misunderstand how those things work?

3.  Which of the checks should be compile time and which runtime?

Thanks!

This was tested with GNAT Community 2018 if that helps.

Re: Anonymous Access and Accessibility Levels

[J-P. Rosen]

Le 20/04/2019 à 17:29, Jere a écrit :
> I was trying to get a bit better at understanding how accessibility
> levels work with respect to anonymous access types.  I have GNAT to
> test out things, but I think I am running into various bugs, so I am
> not seeing the exceptions or compilation errors I would expect.  It
> could also be that I misunderstand the rules (They are difficult
> somewhat).
In my tutorial about memory management, I explain that there are 34 
special cases in 3.10.2 (AKA "heart of darkness"). Enter at your own risk.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:q9ffjn$4kv$1@dont-email.me...
> Le 20/04/2019 à 17:29, Jere a écrit :
>> I was trying to get a bit better at understanding how accessibility
>> levels work with respect to anonymous access types.  I have GNAT to
>> test out things, but I think I am running into various bugs, so I am
>> not seeing the exceptions or compilation errors I would expect.  It
>> could also be that I misunderstand the rules (They are difficult
>> somewhat).
> In my tutorial about memory management, I explain that there are 34 
> special cases in 3.10.2 (AKA "heart of darkness"). Enter at your own risk.

That's all? ;-) I would have guessed in the 60s (although it may matter as 
to how you count).

                            Randy.

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:a89faa70-f56a-4c33-967e-ddb24eaa8a8b@googlegroups.com...
...
> I think that D.The_T has an accessibility level relative to where
> an object of type D is declared?

Yes, but there are special rules for allocators, for objects created as 
return objects, and many other special cases. This area is not for the faint 
of heart. In fact, it is only for those that like beating their heads 
bloody.

As always, I suggest the following rules:

(1) Do not use anonymous access types unless you absolutely need one of the 
special capabilities that can only be done with them.
(2) Under no circumstances, do anything that cannot be checked statically. 
(So no one should use dynamic accessibility checks of anonymous access 
parameters or SAOAATs).
(3) Think three times before depending upon access parameter dispatching and 
anonymous access-to-subprograms.
   (A) If you find that you really need these things, complain to the ARG 
that you should be able to but cannot do these things with named access 
types. (This limitation is idiotic, as it requires repeating long 
declarations at every usage.) [I need help getting this fixed!!]
(4) Keep access types out of visible specifications (since they make memory 
management much harder, and locks in clients to suboptimal memory 
managment).

                                                       Randy.

Re: Anonymous Access and Accessibility Levels

[Shark8]

On Monday, April 22, 2019 at 4:11:20 PM UTC-6, Randy Brukardt wrote:
> 
> As always, I suggest the following rules:
> 
> (1) Do not use anonymous access types unless you absolutely need one of the 
> special capabilities that can only be done with them.
Agreed. Anonymous access types were a mistake — I still stand by my assertion that they should be eliminated from the language, even at the cost breaking backwards compatibility. [This would, of course, entail having real solutions to the problems that they "address" (like first-class subprograms, closures, etc).]

> (2) Under no circumstances, do anything that cannot be checked statically. 
> (So no one should use dynamic accessibility checks of anonymous access 
> parameters or SAOAATs).
I'm unfamiliar with SAOAAT; but I agree with the premise: static-checking is much preferable to run-time checking.

> (3) Think three times before depending upon access parameter dispatching and 
> anonymous access-to-subprograms.
>    (A) If you find that you really need these things, complain to the ARG 
> that you should be able to but cannot do these things with named access 
> types. (This limitation is idiotic, as it requires repeating long 
> declarations at every usage.) [I need help getting this fixed!!]
I'll keep it in mind.
(Weren't there supposed to be two other [sub]items here?)

> (4) Keep access types out of visible specifications (since they make memory 
> management much harder, and locks in clients to suboptimal memory 
> managment).
Indeed. Opaque/private types are quite nice.

Re: Anonymous Access and Accessibility Levels

[Dmitry A. Kazakov]

On 2019-04-23 00:11, Randy Brukardt wrote:

> (3) Think three times before depending upon access parameter dispatching and
> anonymous access-to-subprograms.

So long there is no way to pass a subprogram as a parameter anonymous 
access to subprogram remain unavoidable.

One could use a generic, but 1) it is very heavy weight and 2) the 
instance of cannot be primitive operation:

    type T is tagged ...
    procedure Foo (X : in out T; F : <subprogram>);

What do you have against dispatching access parameters? I think of it as 
once we have access types, we should also have controlling access 
parameters. If we want to push for all named access types then we need 
some form of multi-methods:

    type T is tagged ...
    type T_Ptr is access T;
    procedure Foo (X : T_Ptr); -- I want this in T'Class, somehow

    type S is new T with ...;
    overriding procedure Foo ... -- How?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:16b6432c-c5f4-4504-887b-b7c35ad69e86@googlegroups.com...
On Monday, April 22, 2019 at 4:11:20 PM UTC-6, Randy Brukardt wrote:
...
>> (2) Under no circumstances, do anything that cannot be checked 
>> statically.
>> (So no one should use dynamic accessibility checks of anonymous access
>> parameters or SAOAATs).
>I'm unfamiliar with SAOAAT; but I agree with the premise: static-checking 
>is
>much preferable to run-time checking.

Sorry, used a ARG-ism. SAOAAT = Stand-Alone Object of an Anonymous Access 
Type.

                        Randy. 

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:q9mfor$1fn6$1@gioia.aioe.org...
> On 2019-04-23 00:11, Randy Brukardt wrote:
>
>> (3) Think three times before depending upon access parameter dispatching 
>> and
>> anonymous access-to-subprograms.
>
> So long there is no way to pass a subprogram as a parameter anonymous 
> access to subprogram remain unavoidable.

True, but that was my point: "Complain to the ARG where the capabilities 
aren't available with named access types". The fact that these things are 
anonymous mean you have to give the declaration on every silly usage, that 
you can't give contracts or other properties (no aspects for anonymous 
types), and the readability suffers because of the nested parameter lists.

...
> What do you have against dispatching access parameters? I think of it as 
> once we have access types, we should also have controlling access 
> parameters. If we want to push for all named access types then we need 
> some form of multi-methods:
>
>    type T is tagged ...
>    type T_Ptr is access T;
>    procedure Foo (X : T_Ptr); -- I want this in T'Class, somehow
>
>    type S is new T with ...;
>    overriding procedure Foo ... -- How?

I'd prefer to avoid using access types in specs altogether. But I do realize 
that some sort of reference is needed. I've been working on the 
"simultaneous derivation" problem posed by such types (for instance a Vector 
and Cursor ought to be derived together). I think I've found an actual 
solution, but it's likely too late for Ada 2020 (and it won't work for the 
existing containers, as it involves having multiple different tagged types 
as parameters, which is currently illegal).

                                    Randy.

Re: Anonymous Access and Accessibility Levels

[Jere]

On Monday, April 22, 2019 at 6:11:20 PM UTC-4, Randy Brukardt wrote:
> "Jere" wrote in message 
> ...
> > I think that D.The_T has an accessibility level relative to where
> > an object of type D is declared?
> 
> Yes, but there are special rules for allocators, for objects created as 
> return objects, and many other special cases. This area is not for the faint 
> of heart. In fact, it is only for those that like beating their heads 
> bloody.
> 
> As always, I suggest the following rules:
> 
> (1) Do not use anonymous access types unless you absolutely need one of the 
> special capabilities that can only be done with them.
> (2) Under no circumstances, do anything that cannot be checked statically. 
> (So no one should use dynamic accessibility checks of anonymous access 
> parameters or SAOAATs).
> (3) Think three times before depending upon access parameter dispatching and 
> anonymous access-to-subprograms.
>    (A) If you find that you really need these things, complain to the ARG 
> that you should be able to but cannot do these things with named access 
> types. (This limitation is idiotic, as it requires repeating long 
> declarations at every usage.) [I need help getting this fixed!!]
> (4) Keep access types out of visible specifications (since they make memory 
> management much harder, and locks in clients to suboptimal memory 
> managment).
> 
>                                                        Randy.

I can appreciate that.  I'm not talking about exposing any access
types to the client.  However, I am needing to use an access type
and named access types are insufficient in this case.  While I agree
that compile time checking is preferred, Ada does not provide this
capability in all cases and sometimes I have to rely on runtime
checking (which I still believe is better than manual checking).  In 
either case, I am still interested in understanding those specific
things I asked earlier.  In particular, if the issues I outlined
in Test_AA_2 and Test_AA2 GNAT bugs or some special case rule that
I am missing.  Additionally, I was curious if assignment I highlighted
in the main procedure was also a GNAT bug or a special rule.  My
gut says they are bugs, but I am not 100% sure.

Re: Anonymous Access and Accessibility Levels

[Jere]

On Saturday, April 20, 2019 at 11:58:48 AM UTC-4, J-P. Rosen wrote:
> Le 20/04/2019 à 17:29, Jere a écrit :
> > I was trying to get a bit better at understanding how accessibility
> > levels work with respect to anonymous access types.  I have GNAT to
> > test out things, but I think I am running into various bugs, so I am
> > not seeing the exceptions or compilation errors I would expect.  It
> > could also be that I misunderstand the rules (They are difficult
> > somewhat).
> In my tutorial about memory management, I explain that there are 34 
> special cases in 3.10.2 (AKA "heart of darkness"). Enter at your own risk.
> 
> -- 
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.fr

I'm definitely aware of the HoD and its reputation.  I am a bit 
discourage that there is not any resource (person or written)
available to help newcomers (or heck even somewhat experienced
Ada programmers) with issues like these.  I know I cannot rely
on the compiler to do it correctly in every case, so whether
it compiles and runs without exception or not is not a reliable
indicator.

Re: Anonymous Access and Accessibility Levels

[Jere]

On Wednesday, April 24, 2019 at 6:34:03 AM UTC-4, Jere wrote:
> In either case, I am still interested in understanding those specific
> things I asked earlier.  In particular, if the issues I outlined
> in Test_AA_2 and Test_AA2 GNAT bugs or some special case rule that
> I am missing.  

Sorry, meant Test_AA_2 and Test_AA_3 there.

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:a45b6efd-28da-46ab-9d5e-d5f3423a8f99@googlegroups.com...
> On Wednesday, April 24, 2019 at 6:34:03 AM UTC-4, Jere wrote:
>> In either case, I am still interested in understanding those specific
>> things I asked earlier.  In particular, if the issues I outlined
>> in Test_AA_2 and Test_AA2 GNAT bugs or some special case rule that
>> I am missing.
>
> Sorry, meant Test_AA_2 and Test_AA_3 there.

I discussed this before, but you might have missed it. There are special 
rules for discriminants in many different contexts, so there is no "gut 
feel" that you can use with them. One can only read the rules in detail for 
each particular case. Generally, it's not worth the effort.

I remember (I haven't looked back at your test) that you had some function 
returns involved. That's one of the special cases, and I'm pretty sure those 
were legal.

In any case, I don't believe that dynamic accessibility checking buys 
anything at all. Indeed, 98% of my code has to resort to 'Unchecked_Access 
in order to be compilable at all. I generally wrap the uses in a controlled 
type that cleans up the accesses as needed (that's how Claw works, for 
instance). The dynamic checks are mainly a hazard to be avoided rather than 
anything helpful. (Unlike a static check, it's hard to prove that a dynamic 
check can't fail, so it remains as a hazard for a future call added in 
maintenance.)

                                                      Randy.

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:ce96c027-79d6-4185-96ce-95823f637d8f@googlegroups.com...
...
>I'm definitely aware of the HoD and its reputation.  I am a bit
>discourage that there is not any resource (person or written)
>available to help newcomers (or heck even somewhat experienced
>Ada programmers) with issues like these.

It takes quite of bit of mental effort for even an ARG member like Tucker or 
myself to want to even open 3.10.2. We even have a standing joke about 
sending in a search party if someone doesn't come back from the trip.

The main problem is that even an experienced hand can get confused by all of 
the rules and special cases, and one minor mistake can snowball into a 
completely wrong conclusion. It's simply not for the faint of heart.

I suspect that accessibility implemented by compilers is essentially 
whatever the ACATS tests require. I know that I've never spent time on it in 
Janus/Ada beyond that -- it simply isn't worth self-inflicted pain. Thus, my 
advice is that accessibility works like one would expect in basic cases, and 
do not go beyond basic cases unless you like pain.

                                     Randy.

Re: Anonymous Access and Accessibility Levels

[Optikos]

On Wednesday, April 24, 2019 at 6:27:54 PM UTC-5, Randy Brukardt wrote:
> "Jere" <jhb.chat@gmail.com> wrote in message 
> news:ce96c027-79d6-4185-96ce-95823f637d8f@googlegroups.com...
> ...
> >I'm definitely aware of the HoD and its reputation.  I am a bit
> >discourage that there is not any resource (person or written)
> >available to help newcomers (or heck even somewhat experienced
> >Ada programmers) with issues like these.
> 
> It takes quite of bit of mental effort for even an ARG member like Tucker or 
> myself to want to even open 3.10.2. We even have a standing joke about 
> sending in a search party if someone doesn't come back from the trip.
> 
> The main problem is that even an experienced hand can get confused by all of 
> the rules and special cases, and one minor mistake can snowball into a 
> completely wrong conclusion. It's simply not for the faint of heart.
> 
> I suspect that accessibility implemented by compilers is essentially 
> whatever the ACATS tests require. I know that I've never spent time on it in 
> Janus/Ada beyond that -- it simply isn't worth self-inflicted pain. Thus, my 
> advice is that accessibility works like one would expect in basic cases, and 
> do not go beyond basic cases unless you like pain.
> 
>                                      Randy.

It sure seems like this is a problem:  when the language definition is so complex in English prose that even standardization-committee members and compiler-authors have immense difficulty utilizing it, then perhaps that is an A#1 indicator that English prose is itself the problem.  Perhaps Algol68's two-level grammar (or analogous different programmatically-readable specification 51 years later) specifying the rich semantic behavior as mapped into syntax was a step in the right direction after all, despite blowing everyone's minds at the time 51 years ago.

Although Ada's primary problem is lack of equal-sized* or greater-sized* competitor to GNAT, Ada's second-most problem is a specification that is in natural-language prose.

* as measured by mindshare in the marketplace

Ed/Shark8, this is the niche for Byron to chart new territory (as a 2019 total rethink of what the two-level grammar tried to do in Algol68) to make a major contribution.

Re: Anonymous Access and Accessibility Levels

[G.B.]

On 24.04.19 12:42, Jere wrote:

> I'm definitely aware of the HoD and its reputation.  I am a bit
> discourage that there is not any resource (person or written)
> available to help newcomers (or heck even somewhat experienced
> Ada programmers) with issues like these.

It might be too late when designs involving anonymous access
types become issues, but then any design can possibly
have fewer issues if the Ada Rationale is first consulted.
I'm concluding this in part observing designs of programmers who
have chosen to transport a pointer-based mind set to Ada.
This means, they are perhaps not aware of the Rationale.

As an additional consequence, if GNAT advises to use pointer
types, programmers may not always be given the best advice
from a design point of view, only from a compiler that cannot
undo designs.

Re: Anonymous Access and Accessibility Levels

[Jere]

On Thursday, April 25, 2019 at 10:47:59 PM UTC-4, Optikos wrote:
> On Wednesday, April 24, 2019 at 6:27:54 PM UTC-5, Randy Brukardt wrote:
> > "Jere" wrote in message 
> > ...
> > >I'm definitely aware of the HoD and its reputation.  I am a bit
> > >discourage that there is not any resource (person or written)
> > >available to help newcomers (or heck even somewhat experienced
> > >Ada programmers) with issues like these.
> > 
> > It takes quite of bit of mental effort for even an ARG member like Tucker or 
> > myself to want to even open 3.10.2. We even have a standing joke about 
> > sending in a search party if someone doesn't come back from the trip.
> > 
> > The main problem is that even an experienced hand can get confused by all of 
> > the rules and special cases, and one minor mistake can snowball into a 
> > completely wrong conclusion. It's simply not for the faint of heart.
> > 
> > I suspect that accessibility implemented by compilers is essentially 
> > whatever the ACATS tests require. I know that I've never spent time on it in 
> > Janus/Ada beyond that -- it simply isn't worth self-inflicted pain. Thus, my 
> > advice is that accessibility works like one would expect in basic cases, and 
> > do not go beyond basic cases unless you like pain.
> > 
> >                                      Randy.
> 
> It sure seems like this is a problem:  when the language definition is so complex in English prose that even standardization-committee members and compiler-authors have immense difficulty utilizing it, then perhaps that is an A#1 indicator that English prose is itself the problem.  Perhaps Algol68's two-level grammar (or analogous different programmatically-readable specification 51 years later) specifying the rich semantic behavior as mapped into syntax was a step in the right direction after all, despite blowing everyone's minds at the time 51 years ago.
> 

The other problem this causes is that erodes trust in the Ada standard.
If there is no practical way to verify if something is valid Ada via
the standard (since it is not readable in specific areas), then one is
left to only hope that it is correct.  This is very shaky ground to be on.

It's hard to trust that the standard is fully correct.  It's made by 
people and people, no matter how smart, do make mistakes.

As an example, right now, since it compiles in GNAT, and I cannot
verify that it is valid Ada or not via the standard, I am left to
conclude that in this area, Ada does accept dangling anonymous
access types in some situations.  I don't like that conclusion, but
there isn't any reliable way to verify/correct that otherwise.

Re: Anonymous Access and Accessibility Levels

[Jere]

On Friday, April 26, 2019 at 1:12:43 PM UTC-4, G.B. wrote:
> On 24.04.19 12:42, Jere wrote:
> 
> > I'm definitely aware of the HoD and its reputation.  I am a bit
> > discourage that there is not any resource (person or written)
> > available to help newcomers (or heck even somewhat experienced
> > Ada programmers) with issues like these.
> 
> It might be too late when designs involving anonymous access
> types become issues, but then any design can possibly
> have fewer issues if the Ada Rationale is first consulted.
> I'm concluding this in part observing designs of programmers who
> have chosen to transport a pointer-based mind set to Ada.
> This means, they are perhaps not aware of the Rationale.
> 
> As an additional consequence, if GNAT advises to use pointer
> types, programmers may not always be given the best advice
> from a design point of view, only from a compiler that cannot
> undo designs.

I'm not sure the Rationale covers all of the use cases where 
access types end up being needed.  I know working in a lot of
non heap based designs (no heap on my chip), General access types
occasionally have to be used as part of the innards of some 
complex type.  Named access types are too restrictive and end up
requiring the use of Unchecked_Access and in some other cases can 
lead to bad designs when used.  That leaves anonymous access types, 
which seem incomplete.  Ada needs safe access types that are 
more flexible than named access types.  They don't have to be 
anonymous necessarily, but they are a gap in the language design,
especially when you are dealing with limited types, which have 
no container support or similar, so the standard ways of avoiding
access types don't apply.

Re: Anonymous Access and Accessibility Levels

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:a3d74466-9f8a-483f-bdd4-4752439d79f0@googlegroups.com...
...
 I know working in a lot of
> non heap based designs (no heap on my chip), General access types
> occasionally have to be used as part of the innards of some
> complex type.

This is reasonable...

> Named access types are too restrictive and end up
> requiring the use of Unchecked_Access

...and so is this. In my experience, accessibility checking buys nothing but 
headaches. (Static) accessibility checking was defined for the narrow case 
of building non-heap-based library-level structures out of a bunch of 
objects. It works well for that, and pretty much not at all for much else. 
(It has some benefit for class-wide operations where is prevents the use of 
non-existent types, but that's unrelated to access types at all.)

> ... and in some other cases can
> lead to bad designs when used.  That leaves anonymous access types,
> which seem incomplete.

You mean "evil". :-) The problem with anonymous access types is that they 
require repeating important parts of the declaration over and over and over, 
and on top of which they can't have contracts or representation controlled. 
The fact that some capabilities are available *only* with them is a major 
fault of Ada, in my opinion, since it means that you have to chose between 
dynamic checking or contracts or representation control or closure ability 
(for subprograms). Blah!

For access-to-object types, switching to anonymous access just gives you a 
mess of accessibility rules, the special ones for discriminants and 
parameters being the most interesting. The dynamic accessibility checks for 
parameters is primarily a hazard (if used) and useless oveerhead (if not 
used, which is the usual case). Moreover, dymanic accessibility checking is 
known not be to be implemented correctly by any existing compiler for Ada 
2005 or later (a correct implementation is rather expensive). We actually 
considered eliminating it completely and just ruling some cases erroneous, 
since that is closer to actual practice, but that was eventually rejected as 
pushing Ada in the wrong direction.

> Ada needs safe access types that are
> more flexible than named access types.

Sure, and we need strings that work perfectly and a bunch of other 
holy-grail-like things that are likely to be unacheviable in practice. Rust 
demonstrated that "safe access types" aren't very usable (especially as Ada 
already allows direct declaration of many objects that other languages only 
allow creating by allocation); they work for limited problems but not to 
build significant data structures.

I'm skeptical that anything that works will be usable enough for the effort. 
I'd love for someone to prove me wrong on this, but I don't see it 
happening. The root problem is that the need for some sort of long-lived 
reference (critical for performance reasons, may be necessary for other 
reasons as well) is always going to be at odds with any sort of

> They don't have to be
> anonymous necessarily, but they are a gap in the language design,
> especially when you are dealing with limited types, which have
> no container support or similar, so the standard ways of avoiding
> access types don't apply.

Which of course begs the question of whether the problem really lies with 
limited types. Are they really worth the problems that they introduce? I 
know from experience (Claw makes almost all types non-limited specifically 
because limited types are so, well, limited) that making types non-limited 
that are naturally limited can be painful as well. So here I definitely 
don't know the right answer. (This is the case, where there are no internal 
access types, where a Rust-like solution does work. So perhaps it is worth 
having for dealing with limited objects?? But note that such a solution only 
works with *allocated*, pool-specific objects, so it seems unusable with 
environments that can't use pools.)

                                                     Randy.