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 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Private extension of a synchronized interface Date: Mon, 18 Feb 2019 16:35:13 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 18 Feb 2019 22:35:13 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="2874"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:55573 Date: 2019-02-18T16:35:13-06:00 List-Id: "Jere" wrote in message news:fd975d66-8e70-4e86-8a75-efc6061ef25c@googlegroups.com... > I'll get to my ultimate goal later, but while following various > rabbit trails, I came across a situation I couldn't solve. GNAT > allows you to make private extensions to synchronized interfaces > and it allows you to complete those private extensions with > protected types. I can't, however, figure out how it overrides > the abstract procedures and functions of the synchronized interface. > > If I don't specify an override and try to call the procedure, it complains > that the procedure is abstract. This appears to be a GNAT bug, although I'm not 100% certain. When you inherit abstract routines for a concrete type, the routines "require overriding" routines. (Se 3.9.3(6/4). Such routines have to be overridden (somewhere), which can happen in the private part. And the ultimate routine should be treated as concrete - that is, you should be able to call it. Since your private extension doesn't include the keyword "abstract", that makes the routines "shall be overridden". So I think this is a GNAT bug. Almost everyone (and every compiler) confuses inheriting abstract subprograms with subprograms that require overriding; I know that the terminology and requirements were different in early Ada 9x, but why current compilers continue that mistake is a mystery to me. The reason I don't say this for 100% certain is that "implemented by" is not exactly the same as "overriding" (for reasons that have nothing to do with this issue), and it's not clear to me that the 3.9.3(6) rule actually allows "implemented by". But, it's clear that the intent is that these are equivalent in such cases, and if someone disagress, I'd expect the ARG to take it up and fix the language. What I'd suggest in this case is to create a self-testing example as a potential ACATS test. I'd guess that a case like this doesn't happen in the ACATS, but this a fundemental enough capabilitity that is makes sense for an example to be in the test suite. (Generally, we don't try to test combinations of rules in the ACATS, and this is such a combination. But there are cases where testing the individidual rules don't prove anything about the combination, and this appears to be such a case. That is, the implementation of protected type abstract rules are probably quite different from the normal subprogram rules, so just testing the normal case doesn't prove much. (You can find out details about writing ACATS tests at http://www.ada-auth.org/acats-files/4.1/docs/UG-E.HTM, although getting everything perfect is neither necessary nor likely). Then submit the test to either the agent (agent@ada-auth.org) or to the ACATS-Test@ada-auth.org mailing list. And of course report the issue to AdaCore as well. Since this is an Ada 2005 issue, it applies to a variety of other Ada compilers, and it should be checked for everyone. Moreover, having a test makes it easy to bring any objections to the ARG. Your concrete subprogram declaration is legal, but I would expect that it needs a body. So forget that, it shouldn't be necessary in any case. (The inherited subprogram should be concrete by 3.9.3(6), and then either the type is legal (if properly overriding happens) or the unit is illegal -- there are no other possibilities allowed by the language.) Randy.