From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:4e0b:: with SMTP id c11-v6mr6751875iob.22.1532452504245; Tue, 24 Jul 2018 10:15:04 -0700 (PDT) X-Received: by 2002:aca:c6ca:: with SMTP id w193-v6mr190411oif.1.1532452504048; Tue, 24 Jul 2018 10:15:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!g2-v6no1102744itf.0!news-out.google.com!k71-v6ni1328itk.0!nntp.google.com!d7-v6no1136705itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 24 Jul 2018 10:15:03 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <40d568da-4715-42de-8e28-98da39a5c974@googlegroups.com> <34f499f7-020f-4dcc-adad-0ab1113386d1@googlegroups.com> <9d69e7b5-6b2d-4607-9f7b-affa78c41620@googlegroups.com> <41c711cb-0300-4a41-93d3-e69297ae1945@googlegroups.com> <42de4aa3-9e7c-44b8-aa84-712cc7ce03c6@googlegroups.com> <9b6b6f10-5956-4a19-83f5-c1c015c62602@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com> Subject: Re: Visibility of Indexing aspects From: "Dan'l Miller" Injection-Date: Tue, 24 Jul 2018 17:15:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53953 Date: 2018-07-24T10:15:03-07:00 List-Id: On Monday, July 23, 2018 at 10:32:04 PM UTC-5, Randy Brukardt wrote: > "Jere" wrote in message=20 > 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. >=20 > They're two separate-but-related declarations. You can tell if something = is=20 > a declaration by looking at the name of its syntax. If the syntax include= s=20 > "_declaration", then it's a declaration. And since we have=20 > private_type_declaration and full_type_declaration, they're both=20 > declarations. (See RM 3.1 for the more formal definitions.) >=20 > There are implicit declarations as well, of course, but they don't have= =20 > anything to do with this particular question. But where is =E2=80=9Cassociated=E2=80=9D (as quoted from the _LRM_) define= d as clearly not meaning =E2=80=9Crelated=E2=80=9D (as quoted from Randy's = reply)? AdaMagica overtly claims (and Randy less directly seems to affirm) that onl= y the private declaration of Container is =E2=80=9Cassociated=E2=80=9D in t= he _LRM_. Conversely, Randy directly claims that the public declaration of= Container is =E2=80=9Crelated=E2=80=9D (but presumably not =E2=80=9Cassoci= ated=E2=80=9D). Unless these =E2=80=9Cassociated=E2=80=9D and =E2=80=9Crel= ated=E2=80=9D 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 =E2=80=9Cassociated=E2=80=9D and =E2=80= =9Crelated=E2=80=9D do not give definitions that definitively say that the = public declaration of Container is =E2=80=9Crelated=E2=80=9D but not =E2=80= =9Cassociated=E2=80=9D to the private declaration of Container. (This is w= hat I mean a few replies ago about =E2=80=98sloppy definitions=E2=80=99.) And if this ambiguity (that clearly AdaCore interpreted differently than vi= a this thread's logic) is resolved by making the OP's code illegal, then wh= at would be the adjustment to the OP's code to attain that intended & evoke= d 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;=20 with Ada.Text_IO; use Ada.Text_IO;=20 procedure jdoodle is=20 package Containers is=20 type Container is private with Variable_Indexing =3D> Reference; OR type Container is private record with Variable_Indexing =3D> Reference; OR type Container is private tagged record with Variable_Indexing =3D> Reference; =20 private=20 type Container_Array is array(1..20) of aliased Integer;=20 type Container is tagged record=20 Data : Container_Array :=3D (others =3D> 0);=20 end record; =20 type Reference_Holder=20 (Element : not null access Integer)=20 is limited null record=20 with Implicit_Dereference =3D> Element;=20 =20 function Reference=20 (Self : aliased in out Container;=20 Index : Positive)=20 return Reference_Holder=20 is (Element =3D> Self.Data(Index)'Access);=20 =20 end Containers;=20 =20 C : aliased Containers.Container;=20 begin=20 for Index in 1 .. 20 loop=20 C(Index) :=3D Index;=20 Put_Line(Integer'Image(C(Index)));=20 end loop;=20 end jdoodle;