Re: Ada Successor Language

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

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

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

In any case, it is technically impossible for the above to be true in 
Janus/Ada (the body is a regular compilation unit that is shared with all 
instances - it is never looked at during an instantation and the compiler 
doesn't have any saved information with which to do that anyway).

                                            Randy.



>> I don't think it was a mistake
>> for C++ to have generics since the generic approach in C++ is IME much
>> better than the OO approach with inheritance.
>
> This is evidently wrong. Ada programs extensively using generics are as 
> impossible to maintain as C++ programs using templates. IMO generics have 
> no place in SW engineering.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de