Re: Running a preprocessor from GPS?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 15-07-30 01:32 , EGarrulo wrote:
> On Wednesday, July 29, 2015 at 10:32:16 PM UTC+2, Randy Brukardt wrote:
>> "EGarrulo" wrote in message

>>> Generics *are* glorified macros anyway, in a sense.
>>
>> This is an especial sore point with me!
>>
>> Formally in the Ada RM they are, which causes all manner of nonsense effects
>> which then get erased by special rules. Stupid.
>
> What do you mean?  Conceptually, generics are macros.

Randy Brukardt's message already explained why Ada generics are 
conceptually *not* macros, but perhaps his answer was too focused on how 
his compiler (Janus/Ada) implements generics and not enough on the 
conceptual point.

The aim of Ada generics is to make program components parametrizable by 
types in a safe and predictable way. (In Ada 83, generics were also the 
only way to parametrize program components by operations, but now there 
are other ways to do that.)

The "generic contract" idea in Ada is that the generic declaration 
alone, without looking at the body, gives enough information about the 
generic's formal parameters to decide two things at compile-time:

1. Whether an implementation (body) of the generic is legal, that is, 
uses only the declared properties of the generic formal parameters.

2. Whether an instantiation of the generic with particular actual 
parameters (actual types, etc.) is legal, that is, whether the actual 
parameters have all the properties declared for the generic formal 
parameters.

Thus, compile-time error messages for an illegal generic instantiation 
need only point out discrepancies between the declaration of the generic 
and the actuals in the instantiation. These error messages do not need 
to refer to the body of the generic.

Contrast this with C macros, which are pure text substitution which 
means that the compiler's error messages refer to the definition of the 
macro and can be quite obscure. Similarly, errors in C++ template 
instances are usually detected when the body of the template is compiled 
with the actual template parameters substituted for the formals, and 
again the error messages refer to and must be interpreted by looking at 
the body of the template ("body" is probably not the correct C++ term, 
sorry, I hope my meaning is clear).

This conceptual difference is related to the fact that the theoretical 
computational power of Ada generic instantiation is far below that of 
C++ template instantiation, which is Turing-complete.

 > If a compiler is clever enough to reuse a common implementation,
 > then kudos to the writers of that compiler, but such behaviour
 > shouldn't be a requirement, I think.

The generic contract concept is rather equivalent to a requirement that 
it shall be *possible* to implement generics with shared code. However, 
the generic contract concept is programmer-oriented, not 
compiler-oriented. The choice between shared code or instance-specific 
code is a pragmatic one -- for example, I suspect that the choice of 
shared code in Janus/Ada was influenced by its original 
memory-constrained target processors. Most of GNAT's targets are not so 
memory-constrained.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .