Re: Visibility of Indexing aspects

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, July 25, 2018 at 12:37:53 AM UTC-5, Randy Brukardt wrote:
> I'm not even going to try to figure out what you are talking about. Perhaps 
> a few facts would help:
> 
> A private_type_declaration and a full_type_declaration are both 
> declarations, with their own visibility. But they declare different  *views* 
> of the *same* entity (a type in this case). Ada has many such pairs of 
> declarations (usually, the second one is called a completion, see 3.11.1). 
> Type aspects apply to the type, never the view, so the value is the same for 
> all views. There are some aspects which whether or not you can use them 
> depends on whether they are visible (given on the private type) -- but the 
> *value* of the aspect is the same for all views (it just might be hidden). 
> This model is carefully explained in 13.1 and 13.1.1.
> 
> > that clearly AdaCore interpreted differently than via this thread's logic
> 
> It's far more likely that they just made a mistake or omission. Let me give 
> you a bit of reality: 20-25% of new ACATS tests fail when run with the 
> latest compiler. (Those numbers hold for every Ada compiler that I've ever 
> tried.) Ada is simply too large for any implementer to even remember to 
> enforce every rule and implement every possible combination. The reason that 
> the ACATS is so important to Ada is that it provides at least a base line of 
> known-good tests that substantially reduce these.
> 
> Real Ada compiler development tends to be a slog through making ACATS and 
> other in-house tests work while being constantly interrupted with important 
> bugs to fix from one's customers. And then suddenly your boss and/or 
> customers are expecting a new version promised for July (OK, a bit personal 
> here :-) and you need it done yesterday. It's real easy in those conditions 
> to simply forget to do something (like apply visibility to an indexing 
> aspect); if the mistake doesn't show up in a test, it's likely to go 
> undetected until someone trips over it. That sort of thing is rarely an 
> intentional decision (although the occassional shortcut can happen, too, 
> where something is intentionally left unimplemented).
> 
>                                       Randy.
> 
> 
> 
> "Dan'l Miller" wrote in message 
> news:8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com...
> On Monday, July 23, 2018 at 10:32:04 PM UTC-5, Randy Brukardt wrote:
> > "Jere" wrote in message
> > news:dbc94806-dbf9-408d-b8ad-3a159eb85b24@googlegroups.com...
> > ...
> > > Question:  Section 13.1.3 (1/3) says "The declaration with
> > > the aspect_specification is termed the associated declaration."
> > > In the case of the bugged example I gave, the aspect_specification
> > > was with the full view of the type.  Is that then considered the
> > > declaration of the type, or is just the partial view in the public
> > > section considered the declaration?  I am assuming the full view
> > > is still considered the declaration.
> >
> > They're two separate-but-related declarations. You can tell if something 
> > is
> > a declaration by looking at the name of its syntax. If the syntax includes
> > "_declaration",  then it's a declaration. And since we have
> > private_type_declaration and full_type_declaration, they're both
> > declarations. (See RM 3.1 for the more formal definitions.)
> >
> > There are implicit declarations as well, of course, but they don't have
> > anything to do with this particular question.
> 
> But where is "associated" (as quoted from the _LRM_) defined as clearly not 
> meaning "related" (as quoted from Randy's reply)?
> 
> AdaMagica overtly claims (and Randy less directly seems to affirm) that only 
> the private declaration of Container is "associated" in the _LRM_. 
> Conversely, Randy directly claims that the public declaration of Container 
> is "related" (but presumably not "associated").  Unless these "associated" 
> and "related" terms are given definitions overtly in the _LRM_ (or at least 
> illuminating-color commentary in the _AARM_), then relying the commonfolk 
> English dictionary definitions of "associated" and "related" do not give 
> definitions that definitively say that the public declaration of Container 
> is "related" but not "associated" to the private declaration of Container. 
> (This is what I mean a few replies ago about 'sloppy definitions'.)
> 
> And if this ambiguity (that clearly AdaCore interpreted differently than via 
> this thread's logic) is resolved by making the OP's code illegal, then what 
> would be the adjustment to the OP's code to attain that intended & evoked 
> feature (that would be otherwise removed)?  Would this be the replacement to 
> keep the Reference et. al. private?
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure jdoodle is
>     package Containers is
> 
>       type Container is private
>         with Variable_Indexing => Reference;
> OR
>       type Container is private record
>         with Variable_Indexing => Reference;
> OR
>       type Container is private tagged record
>         with Variable_Indexing => Reference;
> 
>     private
> 
>       type Container_Array is array(1..20) of aliased Integer;
>       type Container is tagged record
>          Data : Container_Array := (others => 0);
>       end record;
> 
>       type Reference_Holder
>          (Element : not null access Integer)
>       is limited null record
>          with Implicit_Dereference => Element;
> 
>       function Reference
>          (Self  : aliased in out Container;
>           Index : Positive)
>           return Reference_Holder
>       is (Element => Self.Data(Index)'Access);
> 
>     end Containers;
> 
>     C : aliased Containers.Container;
> begin
>     for Index in 1 .. 20 loop
>         C(Index) := Index;
>         Put_Line(Integer'Image(C(Index)));
>     end loop;
> end jdoodle;

My point is this:  the work-around/fix
1) to the so-called “severe bug” of implicitly leaking private view's declarations into the public view of a package
is to
2) force the programmer to move the formerly-private declarations to be public declarations in that package.

Looking at it from a software engineering perspective** (of the package designer and the user of the package) instead of the compiler implementer, ••forcing the programmer•• to publicly textually leak intended-to-be-private declarations of his/her design is not any better than the •compiler• doing just the minimal amount of clever promotion of just the right pieces of private aspects to public.  #1 is deemed a so-called “severe bug” when the compiler actually successfully cleverly accomplishes the beneficial use-case of hiding of Reference et. al. in the private view, but #2 is admirably ‘working as designed’ when the programmer lets far more* private guts hang out in the public view of the package for all sorts of misuse/abuse by the users of the package.

* far more detail: all of {Reference, Reference_Holder, Container_Array, ...}

In the end, the intended use-case of privately hiding all of {Reference, Reference_Holder, Container_Array, ...} from misuse by users of the public interface of the package is •not• accomplished by option #2 nor by the _LRM_ as currently written.  At least #1's/OP's/GNAT's misinterpretation of the _LRM_ actually accomplished the use-case of inhibiting the misuse/abuse of Reference et. al.  Complying with the _LRM_ as currently written/designed is arguably worse than the so-called “severe bug”, when looked at from the discipline of software engineering** instead of a compiler writer (or language lawyer mechanically turning the crank of the _LRM_'s language).

** as Jean Ichbiah and HOLWG did

Effectively saying ‘Bah humbug’ to software engineering's intended use-case (of privately hiding all of {Reference, Reference_Holder, Container_Array, ...} from misuse by users of the public interface of the package) is arguably worse than the so-called “severe bug”.