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!.POSTED!not-for-mail
From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada Successor Language
Date: Mon, 2 Jul 2018 11:37:40 +0200
Organization: A noiseless patient Spider
Message-ID: <phcrp5$r1o$1@dont-email.me>
References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com>
 <878t7u1cfm.fsf@nightsong.com>
 <c22391d4-94b6-4ed3-96c0-1e9a84c4a99c@googlegroups.com>
 <b1141508-e692-46f6-b536-4a72081dfb45@googlegroups.com>
 <foqeocF7l4fU1@mid.individual.net> <pg949k$jmv$1@dont-email.me>
 <foqjvhF8kskU1@mid.individual.net>
 <776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com>
 <pg9bd9$eo9$1@gioia.aioe.org> <87602fbu2g.fsf@nightsong.com>
 <pgad3n$1sop$1@gioia.aioe.org> <87po0mziqt.fsf@nightsong.com>
 <pgbm5e$c1l$1@gioia.aioe.org> <87fu1izfgs.fsf@nightsong.com>
 <pgd1hq$ca2$1@gioia.aioe.org> <878t75nwad.fsf@adaheads.home>
 <pgqas8$mjm$1@dont-email.me> <ph64fr$1s7$1@franka.jacob-sparre.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 2 Jul 2018 09:37:41 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="b6c6c2d4fb577ecc139d0401855a7a4b";
	logging-data="27704"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+g1EJOsCqZ+j+kz0rwU3it"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
Cancel-Lock: sha1:jg2XD1JiAB8M3Ve/agf0iR6XJzI=
In-Reply-To: <ph64fr$1s7$1@franka.jacob-sparre.dk>
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:53500
Date: 2018-07-02T11:37:40+02:00
List-Id: <comp.lang.ada>

On 29/06/2018 22:23, Randy Brukardt wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:pgqas8$mjm$1@dont-email.me...
>> On 23/06/2018 21:21, Jacob Sparre Andersen wrote:
>>> Dmitry A. Kazakov wrote:
>>>
>>>> 5. No proper separation of interface and implementation. If you used
>>>> Ada generics you would know that successful compilation of a generic
>>>> body means little. Instantiation can always fail even if all formal
>>>> parameters match. The compiler must look into the body not just for
>>>> the sake of optimization and representation, but for validity of
>>>> instantiation, just like in C++. A macro is a macro.
>>>
>>> If the compilation of a generic succeeds, then any instantiation with
>>> actuals matching the formal generic parameters have to succeed, no
>>> matter what's in the implementation of the generic.
>>>
>>> If that somehow isn't the case in the very newest version of the
>>> standard, then the ARG has messed up, and I doubt that.
>>
>> See this one, which is the case that bit me recently:
>>
>> procedure Blah is
>>
>> generic
>> type Something is private;
>> package Duh is type Meh is new Something; end Duh;
>>
>> type Oh is tagged null record;
>>
>> package Ouch is new Duh (Oh);
>>
>> begin
>>     null;
>> end Blah;
> 
> This can be fixed by moving the derived type to the private part. (It's the
> case that causes all of those exceptional rules in the RM "This legality
> rule is also enforced in the private part" -- the rule for the derived type
> is the only known case where that boilerplate rule is *not* needed.)

First time I was caught unaware of this issue was with a generic whose 
purpose was to export the new type to clients. I no longer remember the 
specifics of how I got around that in the end.

Thanks,
Álex.