Re: Ada Successor Language

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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