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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9983e856ed268154 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.89.196 with SMTP id bq4mr1133153pab.26.1344807343842; Sun, 12 Aug 2012 14:35:43 -0700 (PDT) Path: p10ni49508144pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!news-out.readnews.com!transit3.readnews.com!panix!newsfeed-00.mathworks.com!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Sun, 12 Aug 2012 17:35:43 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1344807343 20097 192.74.137.71 (12 Aug 2012 21:35:43 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 12 Aug 2012 21:35:43 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:4tdwOwM7uTqXUMAy7tOMqJZ96WU= Content-Type: text/plain; charset=us-ascii Date: 2012-08-12T17:35:43-04:00 List-Id: "Randy Brukardt" writes: > Well, I don't want to waste more time on this, but I'm annoyed enough that I > will. Umm, ... thanks. I guess. I don't know why you would be annoyed over a technical disagreement. Or a technical misunderstanding, if that's what it is. > First, we're talking about a compilation dependence here, not an elaboration > or semantic dependence. That's not defined formally by the Ada 95 language, Or, to put it in language-lawyer-ese: There's no such thing as "compilation dependence" in Ada. ;-) This is a concept that some compilers define, and they don't all necessarily define it the same way. You shouldn't be surprised that I misunderstood when you use "dependence" in a nonstandard way in a language-lawyer discussion! > but of course it's necessary to any implementation. (I believe it was > formally defined in Ada 83.) I don't remember about Ada 83 -- you're probably right about that. > Anyway, consider: > > package P is > function F return Boolean with Inline; > end P; > > package body P is > function F return Boolean... > end P; > > with P; > procedure Q is > begin > if P.F then ... > end Q; > > Here, Q has a compilation dependence on the body of P. If the body of P is > recompiled, then Q also has to be recompiled. If it is not, then the program > must not be allowed to link. (That would be a violation of 10.1.4(5)). Sure, but I don't see any conformance issue, here. The compiler may require that you recompile Q "by hand" before you can run the program. Or it can do it automatically. Or it could have a separate tool (like gnatmake) that does it automatically. The above is a legal program, and a conforming implementation must provide SOME way to run it. Yours does. GNAT does. (Ada doesn't have a concept of "link", either -- the issue is whether you can run the program.) > Also note that 10.1.4(7/3) talks about "removing" compilation units that > contain calls on inlined units when a new copy of the body is added (and > "preexisting versions" of the body are removed). This has the effect of a > compilation dependence. > > (For Janus/Ada, we don't "remove" units, but we do refuse to bind units that > contain references to old versions. I've always presumed that that was a > correct implementation of these two rules.) Yes, I believe it is correct. You are "removing" it in the sense that the RM means (even though some data might still be there on the disk). > IMHO, compilation dependences should be given in the visible part of the > package (preferable in the context clause), ... OK, now I see what you're getting at. Well, you can't put pragmas Inline in the context clause! You can put them in the visible part, and apparently that's what you want to require. However, that doesn't quite achieve your stated goal. GNAT has a similar concept of compilation dependences, but it also includes generics: if Q instantiates something in P, then if P's body is recompiled, Q needs to be recompiled (and gnatmake will do that automatically). The problem is that the pragma Inline above doesn't necessarily imply a compilation dependence -- it does only if Q calls the inlined thing, and only if inlining is turned on, and only if the compiler is able to do the inlining. At least, that's the way GNAT works. Similarly, for generics, a compilation dependence is only necessary for things that actually instantiate something. (And in your compiler, you never "inline" (i.e. macro-expand) generics, so there's no dependence.) >...so that the 1% of Ada > programmers that compile files by hand can accurately find the dependences. They will recompile things unnecessarily. > Requiring the use of implementation-defined tools like GNAT's Gnatmake or > Janus/Ada's COrder is obnoxious. Thus "Inline" needs to be given in the > visible spec. Shrug. How could failing to satisfy the 1% that use stone axes be "obnoxious". At worst, it's "mildly annoying to a small minority". I wouldn't want to use an Ada compiler that doesn't do automatic recompilation. In fact, GNAT itself is built without using gnatmake, because it's part of gcc, and gcc uses primitive stone-ax-like tools ('make', ...). It's a nightmare. > If 10.1.4(7/3) didn't exist, then Inline would not need to be given in > visible spec. The last sentence of that paragraph is there to avoid requiring Ada 83 compilers to change their ways. >... But as I noted elsewhere, I don't think Inline should be given > anywhere -- compilers can figure out when to Inline better than any human > can. In most cases, yes. I still think there's a place for compiler hints, such as pragma Inline. >... Hints about the amount of space expansion allowed for the entire > program and the relative importance of particular subprograms would be much > more valuable. And profile-guided optimization. And JIT compilation. - Bob