Re: Anonymous Access and Accessibility Levels

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

"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.