Re: Visibility of Indexing aspects

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

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" <optikos@verizon.net> 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;