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:a02:a319:: with SMTP id q25-v6mr10852569jai.44.1532543195391; Wed, 25 Jul 2018 11:26:35 -0700 (PDT) X-Received: by 2002:aca:2b06:: with SMTP id i6-v6mr118511oik.0.1532543195247; Wed, 25 Jul 2018 11:26:35 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!g2-v6no24979itf.0!news-out.google.com!k71-v6ni2742itk.0!nntp.google.com!g2-v6no24975itf.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 25 Jul 2018 11:26:34 -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> <8720f70a-59b1-4297-b2fc-78804ec88b7b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <756cb66b-1ef8-4d9e-b679-118b6c59e89c@googlegroups.com> Subject: Re: Visibility of Indexing aspects From: "Dan'l Miller" Injection-Date: Wed, 25 Jul 2018 18:26:35 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 10534 X-Received-Body-CRC: 3138227983 Xref: reader02.eternal-september.org comp.lang.ada:53960 Date: 2018-07-25T11:26:34-07:00 List-Id: 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. Perha= ps=20 > a few facts would help: >=20 > A private_type_declaration and a full_type_declaration are both=20 > declarations, with their own visibility. But they declare different *vie= ws*=20 > of the *same* entity (a type in this case). Ada has many such pairs of=20 > declarations (usually, the second one is called a completion, see 3.11.1)= .=20 > Type aspects apply to the type, never the view, so the value is the same = for=20 > all views. There are some aspects which whether or not you can use them= =20 > depends on whether they are visible (given on the private type) -- but th= e=20 > *value* of the aspect is the same for all views (it just might be hidden)= .=20 > This model is carefully explained in 13.1 and 13.1.1. >=20 > > that clearly AdaCore interpreted differently than via this thread's log= ic >=20 > It's far more likely that they just made a mistake or omission. Let me gi= ve=20 > you a bit of reality: 20-25% of new ACATS tests fail when run with the=20 > latest compiler. (Those numbers hold for every Ada compiler that I've eve= r=20 > tried.) Ada is simply too large for any implementer to even remember to= =20 > enforce every rule and implement every possible combination. The reason t= hat=20 > the ACATS is so important to Ada is that it provides at least a base line= of=20 > known-good tests that substantially reduce these. >=20 > Real Ada compiler development tends to be a slog through making ACATS and= =20 > other in-house tests work while being constantly interrupted with importa= nt=20 > bugs to fix from one's customers. And then suddenly your boss and/or=20 > customers are expecting a new version promised for July (OK, a bit person= al=20 > here :-) and you need it done yesterday. It's real easy in those conditio= ns=20 > to simply forget to do something (like apply visibility to an indexing=20 > aspect); if the mistake doesn't show up in a test, it's likely to go=20 > undetected until someone trips over it. That sort of thing is rarely an= =20 > intentional decision (although the occassional shortcut can happen, too,= =20 > where something is intentionally left unimplemented). >=20 > Randy. >=20 >=20 >=20 > "Dan'l Miller" wrote in message=20 > 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 somethin= g=20 > > is > > a declaration by looking at the name of its syntax. If the syntax inclu= des > > "_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. >=20 > But where is "associated" (as quoted from the _LRM_) defined as clearly n= ot=20 > meaning "related" (as quoted from Randy's reply)? >=20 > AdaMagica overtly claims (and Randy less directly seems to affirm) that o= nly=20 > the private declaration of Container is "associated" in the _LRM_.=20 > Conversely, Randy directly claims that the public declaration of Containe= r=20 > is "related" (but presumably not "associated"). Unless these "associated= "=20 > and "related" terms are given definitions overtly in the _LRM_ (or at lea= st=20 > illuminating-color commentary in the _AARM_), then relying the commonfolk= =20 > English dictionary definitions of "associated" and "related" do not give= =20 > definitions that definitively say that the public declaration of Containe= r=20 > is "related" but not "associated" to the private declaration of Container= .=20 > (This is what I mean a few replies ago about 'sloppy definitions'.) >=20 > And if this ambiguity (that clearly AdaCore interpreted differently than = via=20 > this thread's logic) is resolved by making the OP's code illegal, then wh= at=20 > would be the adjustment to the OP's code to attain that intended & evoked= =20 > feature (that would be otherwise removed)? Would this be the replacement= to=20 > keep the Reference et. al. private? > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Text_IO; use Ada.Text_IO; >=20 > procedure jdoodle is > 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; > type Container is tagged record > Data : Container_Array :=3D (others =3D> 0); > end record; >=20 > type Reference_Holder > (Element : not null access Integer) > is limited null record > with Implicit_Dereference =3D> Element; >=20 > function Reference > (Self : aliased in out Container; > Index : Positive) > return Reference_Holder > is (Element =3D> Self.Data(Index)'Access); >=20 > end Containers; >=20 > C : aliased Containers.Container; > begin > for Index in 1 .. 20 loop > C(Index) :=3D Index; > Put_Line(Integer'Image(C(Index))); > end loop; > end jdoodle; My point is this: the work-around/fix 1) to the so-called =E2=80=9Csevere bug=E2=80=9D of implicitly leaking priv= ate view's declarations into the public view of a package is to 2) force the programmer to move the formerly-private declarations to be pub= lic declarations in that package. Looking at it from a software engineering perspective** (of the package des= igner and the user of the package) instead of the compiler implementer, =E2= =80=A2=E2=80=A2forcing the programmer=E2=80=A2=E2=80=A2 to publicly textual= ly leak intended-to-be-private declarations of his/her design is not any be= tter than the =E2=80=A2compiler=E2=80=A2 doing just the minimal amount of c= lever promotion of just the right pieces of private aspects to public. #1 = is deemed a so-called =E2=80=9Csevere bug=E2=80=9D when the compiler actual= ly successfully cleverly accomplishes the beneficial use-case of hiding of = Reference et. al. in the private view, but #2 is admirably =E2=80=98working= as designed=E2=80=99 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, Re= ference_Holder, Container_Array, ...} from misuse by users of the public in= terface of the package is =E2=80=A2not=E2=80=A2 accomplished by option #2 n= or by the _LRM_ as currently written. At least #1's/OP's/GNAT's misinterpr= etation of the _LRM_ actually accomplished the use-case of inhibiting the m= isuse/abuse of Reference et. al. Complying with the _LRM_ as currently wri= tten/designed is arguably worse than the so-called =E2=80=9Csevere bug=E2= =80=9D, when looked at from the discipline of software engineering** instea= d of a compiler writer (or language lawyer mechanically turning the crank o= f the _LRM_'s language). ** as Jean Ichbiah and HOLWG did Effectively saying =E2=80=98Bah humbug=E2=80=99 to software engineering's i= ntended use-case (of privately hiding all of {Reference, Reference_Holder, = Container_Array, ...} from misuse by users of the public interface of the p= ackage) is arguably worse than the so-called =E2=80=9Csevere bug=E2=80=9D.