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:aed:3eee:: with SMTP id o43mr54716462qtf.33.1577821212832; Tue, 31 Dec 2019 11:40:12 -0800 (PST) X-Received: by 2002:a9d:24ea:: with SMTP id z97mr84144248ota.345.1577821212607; Tue, 31 Dec 2019 11:40:12 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!g89no877162qtd.0!news-out.google.com!w29ni260qtc.0!nntp.google.com!g89no877157qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 31 Dec 2019 11:40:12 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: <1d96e0e1-7700-4947-9fcb-051a1203c703@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Is this a bug? From: Optikos Injection-Date: Tue, 31 Dec 2019 19:40:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57780 Date: 2019-12-31T11:40:12-08:00 List-Id: On Monday, December 30, 2019 at 5:16:19 PM UTC-6, Randy Brukardt wrote: > "Niklas Holsti" wrote in message=20 > news:h6uum4F2481U1@mid.individual.net... > > On 2019-12-30 19:51, Anh Vo wrote: > >> On Monday, December 30, 2019 at 7:44:37 AM UTC-8, reinert wrote: > >>> Hello, > >>> > >>> assume the following Ada procedure: > >>> ---------------------------------------------------------------------= --------- > >>> with Text_IO; > >>> procedure test1 is > >>> package test_package is > >>> type rec1_t is tagged record > >>> a : integer :=3D 2; > >>> -- b : integer :=3D 2; > >>> end record; > >>> function a(x : rec1_t) return integer is (3); > >>> rec1 : rec1_t; > >>> end test_package; > >>> begin > >>> Text_IO.Put(" test_package.rec1: " &=20 > >>> integer'image(test_package.rec1.a)); > >>> end test1; > >>> ---------------------------------------------------------------------= ---------- > >>> > >>> It gives (for mye computer): > >>> > >>> test_package.rec1: 2 > >>> > >>> If I change the statement > >>> > >>> "a : integer :=3D 2;" > >>> > >>> to > >>> > >>> "b : integer :=3D 2;" > >>> > >>> then I get: > >>> > >>> test_package.rec1: 3 > >>> > >>> Is this reasonable? Bug? > >>> > >>> reinert > >> > >> No, the compiler behaves correctly. In fact, if tagged record is > >> replaced by record, the latter case will be rejected. > > > > Yes. > > > > When rec1_t is tagged, the "selected component" text "test_package.rec1= .a"=20 > > could refer either to the rec1_t-component "a" or to the subprogram=20 > > (function) "a". In RM 4.1.3(9.1/2) and RM 4.1.3(9.2/3), the latter case= is=20 > > available only under the condition that the tagged record type (rec1_t)= =20 > > does not have a (visible) component with the name "a". This means that = the=20 > > ambiguity is resolved in favour of the component "a", which has the val= ue=20 > > 2. > > > > One could ask, why is such an ambiguity not rejected (made illegal)?=20 > > Probably because such an illegality rule would have made many illegal m= any=20 > > Ada programs that were legal before the introduction of the=20 > > "object.operation" syntax for tagged-record objects. >=20 > The other reason is that there isn't any alternative notation available f= or=20 > components, whereas there is an alternative method for function calls. Er= go,=20 > we assume that you mean a component if both are available -- otherwise, i= t=20 > would be impossible to access a component at all if there is a function w= ith=20 > the same name visible. Since that function wouldn't even have to be in th= e=20 > same scope, there would be a significant maintainance hazard. >=20 > Moral: This is another reason to make everything a private type (and also= to=20 > not use prefixed notation with types that aren't private). Another moral to the story: This is a reason for language designers to not import some other language's= syntax in =E2=80=A2verbatim=E2=80=A2 (in Ada95) just because all the cool = OO kids were doing member-dot syntax (during the late-1980s & 1990s). Perh= aps a quite-visual multi-character token would have been better (e.g., dot-= colon .: as a metaphor for zoom-in magnification or colon-dot :. for drill-= down to a part within the whole). Or perhaps tilde (~) or commercial-at (@= ) or back-tick (`) would have been better, if a single-character token was = the only option.