Re: Should Inline be private in the private part of a package spec?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> 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