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!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Ada Successor Language
Date: Sun, 24 Jun 2018 10:34:34 +0200
Organization: Aioe.org NNTP Server
Message-ID: <pgnl2q$19tv$1@gioia.aioe.org>
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>
NNTP-Posting-Host: 3CrKQyqWAJZHy6zYVP/kUg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.8.3
Xref: reader02.eternal-september.org comp.lang.ada:53276
Date: 2018-06-24T10:34:34+02:00
List-Id: <comp.lang.ada>

On 2018-06-23 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.

That is not possible because generic formal contracts are weakly typed. 
Consider, for simplicity, this:

    with Ada.Finalization;
    generic
       type T is new Ada.Finalization.Controlled with private;
    package P is
       type S is new T with null record;
       not overriding procedure Foo (X : S);
    end P;

If the given descendant of Controlled has Foo already, you are out of 
luck. The contract says: any descendant of Ada.Finalization.Controlled. 
That is a lie.

> 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.

No, it is a fundamental problem of the generic formal contracts (and 
macro processing).

No contract can describe all behavior. In the first-order language we 
handle that by adding run-time exceptions. So when you substitute 
Positive where a full Integer is expected you get Constraint_Error and 
since the exception is in the contract, the contract is saved.

In the second-order language, like generics, there is no such escape. 
The "behavior" of a generic program is the generated source text in the 
first-order language to compile. If something goes wrong, the exception 
is compile fault (or letting the garbage through). You can try to

1. strengthen generic formal contracts

2. weaken the generic language

#1 is extremely difficult (if possible) and would lead to explosion of 
RM rules. #2 will render generics useless.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de