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

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 07.08.12 01:09, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07 Aug 2012 01:52:34 +0400:
>
>
>>> They will affect already compiled modules.
>>
>> That's not relevant to specifying subprograms in public parts
>> of a package spec. A subprogram spec is about how to write
>> correct calls of the public subprogram.
>
> BTW, I have menant the same - modules that have used this inlined subprogram and already compiled.
>
>>> As you might know Ada aimed to minimize recompilations.
>>
>> Quality of implementation issue. I think Bob Duff has also explained
>> a few times that incremental compilation might would be a better
>> choice if minimizing recompilations is a goal.
>
> ? I dont see your replica is related to recompilation and inlining.

Advances in compiler technology, or even varying the
compilation processes, should not find a way into
public parts of public packages made for re-use by others.

package Reusable is

   procedure Op (X : T)
      with Inline => True,
           Optimize => Time,
        GNAT_Eliminate => Possibly,
       Rational_Debug_Hook => Yes,
        SofCheck_Inspectable => X;

That's all relevant information in some hypothetical
specific setup, but it is terribly at odds with re-usable Ada.
These aspect are pragmatic, they are not relevant for re-use,
they are extrinsic to Op's meaning.

Notice the signal to noise ratio in LOC when comparing
the lines that inform about the meaning of Op and the
lines that inform about aspects relating to tools and
translation.

A better place would be Bob Duff's idea of a third
file also collecting the representation information.

> What are you about? Rook gambits are tied?

I can call X if I supply proper arguments to X.
Everything else is not normally relevant in order for
me to know the meaning of my program that calls X.

>> Inline can well be hidden here.
>
> The question was - WHY? And for what benefit?

For the benefit of the reader who is concerned with
what his program does when calling X, irrespective
of anything to do with translation, or quality of
the compiler, or distribution format of libraries.


> No, when I call inlined subprogram I can see that this is inlined and I can not use hardware breakpoint, I can not use address of such subprogram widely in my writings, and I can suppose that internal variables if they are shared across inlined copies can cause a jam with locals, and I can not use it as an interrupt handler. From other properties I can take more assumptions what can be inserted in my code.

These are aspects of optimization and debugging,
not aspect of the meaning of the program.
Why would I want to learn about your debugging preferences
when all I want to know is how to call your subprogram properly?

If I do want to know how to optimize, or how to link
some unfortunate library distribution, the necessary information
could be provided in its proper place, which I think is not
what the subprogram is generally about.

>> Writers' convenience usually is a sign of less than co-operative
>> software design, pardon the expression. The focus is on readers'
>> convenience.
>
> By that reader I mean not only human, but also a compiler, a tool for UML processing, and the rest. I think that your approach is entirely against cooperation. Sabotage.

Writing for the compiler is o.K. if tuning a specific
program. However, when writing public parts of packages
for use by others, your compilers and tools do not count.
Not at all. Not in Ada.

  
>> When modelling, pragmatic hints seem all the more irrelevant.
>> When a UML tool starts to dictate how package specifications
>> should be made, I start to worry a little.
>
> Seem for whom?

Seem irrelevant for the one who models: Note that modelling is
different from programming in that the model abstracts things
away that---by the strict definition of modelling---you do care
about when writing whole programs in a programming language,
but not in a modelling language. Otherwise, the two would be
the same.

I know that some want to write programs using graphical
languages. That's not Ada, then, and Ada's principles cannot
apply, otherwise everyone would be writing Ada, not be
manipulating UML diagrams.

> your words sound like stylist, and not a designer. Me dictate to my UML tool what to be made.
> So you should not be worry even a little, since it is not related to you.

If what you do is not related to anyone but you,
why do you comment on what should be added to
specifications of publicly visible subprograms
in packages written for others?


> I suppose as you pay - you dont write them. Probably your way - is to pay for all
> the program

No, I usually get to use modules written by others.
It is always time consuming and costly if an interface appears
to be influenced by the coding habits, or library specifics,
or compiler specific, or version numbers, or tools used,
things to be associated with the writer only.


> Buy ready to use thing - its much less nervous!

Wishful thinking. More than once I have been stopped
by aspects / pragmas that have nothing to do with the arguments
to use when calling a subprogram. For example,

pragma Linker_Options

written by a "cool, pragmatic writer" gets very much in
the way of using packages, all the more when you cannot change
its string argument, or even just comment the dreadful thing!
Pragmas/aspects like these should not be used in re-usable
software!

Ideally, Inline should be easily controllable outside
the source text proper. Again, maybe in a third file that also
has the representation information.

Then, both the supplier and the client of a package could
control aspects like inline that are not intrinsic to
a subprogram. The third file could be switched, everyone
is happy and subprogram specification are not littered
with aspects of specific translations.

> If you know what are you doing (and every contractor's requirement express such knowledge) - why not?

Because everyone-knows-everything and everyone-is-using-the-same-setup
is very un-Ada. It makes software less re-usable.


> This is too serious action to add a brick without approval. Have you tried it on railroads?

I write software, I don't mess with railroads.

Since pragma Inline does not---allusions to anecdotal evidence
not withstanding---change the meaning of a subprogram, adding it
does not change the meaning of the program that calls the subprogram.
Specifying inline is thus not different from switching to higher
optimization, or from upgrading the compiler.
Which is being done carefully (Q&A), but is being done.

>>> A good way is to use Inline as a configuration pragma,
>>
>> Since Inline applies to program units, that won't work.
>
> I have pointed out to pragma Eliminate.

Pragma Eliminate is GNAT specific.  How does this add to the
meaning of subprograms in terms of Ada? What is the best place of a
compiler specific pragma if the goal should be to write for readers who
want to understand how to call a subprogram? I say, the best place is
outside the source code proper.


> The question is still open: Why You have insist that convention is an optimisation?

As mentioned in another post, I have likened the convention
of an import to optimization in the following way:
It is simply not relevant to know the import status of
a subprogram in order to call it, just like it is not relevant
to know its optimization in order to call it.
The meaning does not change, pragmatic aspects will.

Hence, the place where others want to learn how to call a
subprogram is not the place for aspects that apply in very
specific circumstances only. They never affect the text
of the call statement.