Re: Ada Successor Language

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ph6aqs$1cj7$1@gioia.aioe.org...
> On 2018-06-29 22:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:pgd1hq$ca2$1@gioia.aioe.org...
>> ...
>>> 4. No proper reuse. Generic bodies are no proper compilation units, you
>>> cannot have a shared library of generics. Therefore the only possible 
>>> form
>>> of reuse is textual substitution and recompilation of the client code.
>>
>> Since Janus/Ada implements them exactly this way, this is demonstratably
>> false. The lack of reuse in some implementations (i.e. GNAT) is an 
>> intended
>> implementation decision, not a language requirement.
>
> You must use some very special linker/loader then. Considering a generic 
> package like:
>
>    generic
>       type T is private;
>       with function Init return T;
>    package P
>       X : T := Init;
>    end P;
>
> the linker must magically multiply the object X for each instance of the 
> package P and call Init for each of them, none of which it may know in 
> advance.

You've forgotten the magic of a level of indirection. :-) Every generic 
operation takes a (hidden) parameter that is a generic sharing block, and 
that includes all of the package-level data for the generic, information 
about the generic parameters, and more. The linker has nothing to do with 
it.

It's the sharing data and the level of indirection that it implies that 
makes generic sharing run slower than a macro approach.

>>> 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.
>>
>> This is also False. Ada uses "assume-the-worst" rules such that any legal
>> generic body is legal for any possible instantiation. There are 
>> *different*
>> rules for the generic specification, and perhaps you are running afoul of
>> those (those can cause failure of an instantiation). Or of compiler bugs
>> causing compilation failures in instance bodies. Neither make the above
>> true.
>
> Maybe it was bugs. I simply do not know because it is so complicated that 
> there is no way to tell. Usually it involves some name conflict in the 
> body upon instantiation a child generic unit.

That's definitely a bug: the body is a separate name-space from a child.

> BTW, using different rules for specifications and bodies is indicative by 
> itself.

'twasn't my idea. I probably would have treated them the same, with more 
contracts in the formal part. But that would be clearly harder to use, so 
it's hard to be certain that it would be better. It surely would be easier 
to implement (there's some 60 rules that have to be re-enforced in an 
instantiation, all of which require special code in Janus/Ada. I see the 
appeal of GNAT's approach, but then they have to be able to *not* enforce 
those 60 rules in generic instance bodies. Doesn't sound a lot better. :-)

                                              Randy.