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, 25 Jun 2018 10:58:46 +0200
Organization: A noiseless patient Spider
Message-ID: <pgqas8$mjm$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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Jun 2018 08:58:48 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="bb1a2475e556141be9aa21d57c749651";
	logging-data="23158"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1980Kr+5Po1iAG9XBt14+Qz"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
Cancel-Lock: sha1:H+KHEf+DnrU9GcZdVp2MdBbF8PI=
In-Reply-To: <878t75nwad.fsf@adaheads.home>
Content-Language: en-US
Xref: reader02.eternal-september.org comp.lang.ada:53292
Date: 2018-06-25T10:58:46+02:00
List-Id: <comp.lang.ada>

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;