Re: Ada Successor Language

["Randy Brukardt" <randy@rrsoftware.com>]

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

                                   Randy.