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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada Successor Language Date: Fri, 29 Jun 2018 17:36:10 -0500 Organization: JSA Research & Innovation Message-ID: References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <878t7u1cfm.fsf@nightsong.com> <776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com> <87602fbu2g.fsf@nightsong.com> <87po0mziqt.fsf@nightsong.com> <87fu1izfgs.fsf@nightsong.com> Injection-Date: Fri, 29 Jun 2018 22:36:10 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="32227"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:53462 Date: 2018-06-29T17:36:10-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ph6aqs$1cj7$1@gioia.aioe.org... > On 2018-06-29 22:17, Randy Brukardt wrote: >> "Dmitry A. Kazakov" 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.