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!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Generic private type declaration Date: Tue, 29 Nov 2016 12:12:39 +0100 Organization: A noiseless patient Spider Message-ID: References: <877f7qy6hf.fsf@adaheads.sparre-andersen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 29 Nov 2016 11:11:23 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="cc92467b3819344c575b3c585d312c03"; logging-data="32030"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19XD15DYci+6TKkMqsjepgV" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 In-Reply-To: Cancel-Lock: sha1:cA9CRgpAihDGGt+BUQ2eLRxoM9c= Xref: news.eternal-september.org comp.lang.ada:32508 Date: 2016-11-29T12:12:39+01:00 List-Id: On 28/11/16 22:32, Randy Brukardt wrote: > For what it's worth, Janus/Ada is wrong here (it probably isn't making the > recheck of the instance; all of those have to be manually programmed and we > pretty much only implemented the checks that we've seen in ACATS tests or in > our own examples). > > The issue in this case is that type Y is a visible, tagged type outside of > the instance. In that case, we can't allow a derivation without an extension > (both for consistency reasons and I believe there also are semantic > differences between tagged and untagged types). > > But this is the one rule that we intentionally do not use the standard > boilerplate about the legality rule also applying in the private part. > Therefore, your example is legal so long as the derived type is not visible > outside of the generic. Specifically, I think (I didn't try it) that: Thanks for the explanation, Randy, I begin to see the rationale and ramifications of this. Although my example was simplified, it was from a actual case in which indeed the new type was in the public part. I guess I had never encountered this particular situation in 10+ years of Ada so it got me by surprise. Cheers, Alex. > generic > type X is private; > package Untagged is > private > type Y is new X; > end Untagged; > > In this case, there is no place where Y would ever be a tagged type, and > thus it isn't a problem for this to be legal. > > The general principle is that all Ada legality rules are rechecked in the > specification of an instance, using the properties of the actual parameters. > In most cases (for most rules), this doesn't matter (nothing changes), but > there are cases where it matters and those are potentially > contract-breaking. That's annoying, but it is an intergral part of the Ada > model for generics (the alternative would have been to use assume-the-worst > rules in generic specifications, as is done in bodies, but that would make > generics almost useless for tagged types -- no extensions could be done in > generic specs under such a rule -- in particular, a mix-in generic would not > be possible. So, yes, Dmitry, the language could strengthen contracts this > way -- if one didn't care about usability [or compatibility]). > > Randy. > > "Alejandro R. Mosteo" wrote in message > news:o1hh1b$13v$1@dont-email.me... >> On 26/11/16 20:18, Tero Koskinen wrote: >>> 26.11.2016, 10.45, Jacob Sparre Andersen wrote: >>>> Alejandro R. Mosteo wrote: >>>> >>>>> I get in both gnat 4.9.3 and gpl2016 the following error: >>>>> >>>>> b001_tagged.adb:15:04: instantiation error at line 7 >>>>> b001_tagged.adb:15:04: type derived from tagged type must have >>>>> extension >>>>> gnatmake: "b001_tagged.adb" compilation error >>> ... >>>> I suspect that this is an error due to how GNAT expands generics. It >>>> might be useful to try to see how Janus/Ada and ICC/Ada treats it. If I >>>> remember correctly, Janus/Ada implements generics differently from GNAT. >>> >>> Janus/Ada 3.1.2c result here, just a warning on line 13: >>> Input File Is C:\Work\mosteo-generic\B001_TAGGED.ADB >>> Pass II >>> Expected J2inst duplication to be the same >>> >>> >>> In File C:\Work\mosteo-generic\B001_TAGGED.ADB(13) >>> -------------- >>> 12: >>> 13: type Void is tagged null record; >>> ----------------^ >>> *WARNING* Construct allowed only in a package specification (6.4.9) >>> Expected J2inst duplication to be the same >>> Bad or locked TREEFLAG.IN file -- see J3Tree_Debug >>> Pass III - JCode >>> Pass IV - 80386 Family >>> Creating C:\Work\mosteo-generic\B001_TAG.SRL >>> Thank You For Using JANUS/Ada >>> (...) >> >> Thanks to everyone that answered/took the time to test. >> >> So, to summarize: Janus/Ada accepts it, Gnat does not, and some other >> compiler used by G.B. also rejects it. >> >> Cheers, >> Alex. >> >>> >>>> >>>> Greetings, >>>> >>>> Jacob >>>> >>> >>> Yours, >>> Tero >>> >> > >