From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Running a preprocessor from GPS? Date: Thu, 30 Jul 2015 18:23:28 +0300 Organization: Tidorum Ltd Message-ID: References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net K4lKbnt5hUFfnZPzpz1x2AHixPr9ywIMll4U1MBpsaMl3YF2Sm Cancel-Lock: sha1:bPbGwuQ6ws/xxY8zlKQh9OypD8U= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:27219 Date: 2015-07-30T18:23:28+03:00 List-Id: 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 . @ .