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

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

On 06.08.12 23:01, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Mon, 06 Aug 2012 21:58:25 +0400:
>
>> On 06.08.12 17:50, Vasiliy Molostov wrote:
>>> Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме Mon, 06
>>> Aug 2012 18:33:42 +0400:
>>>
>>>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>>>
>
>>> So indeed 'inlining' belongs to subprogram specification in the same way as
>>> calling convention.
>>
>> Inlining and convention are aspects typically related to translation,
>> aspects that would not normally affect the resulting
>> executable program except in the way that, say,
>> optimization switches do.
>
> 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.

> 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.

> Why you have decided that calling convention is an optinization?

What the program does is not a matter of whether or not
some subprogram needs calling convention Ada or StdCall or
some such. Hence, from the perspective of the caller,
knowing the calling convention of an import is distraction
at best.

>> Optimization switches are not usually
>> part of subprogram's public specifications either.
>
> Why (convention) is not a part? What is usually?

I'd expect aspects to let me know what a subprogram does
if I call it with suitable parameters. Aspects of how that
is going to be done in terms of processor instructions
are of no concern at this point.

> Yesterday I wrote some code and it has specs along with inline, just after subprogram spec.
> Today you said that it is not usual. Not usual for whom?

The focus is on the public part of a package spec, to be read by
other programmers. Information hiding might ask for compiler
hints and the like to be put somewhere they do not clutter
the text that conveys meaning, that is, explains what a
subprogram does, and how to call it. Inline can well be hidden
here. Note that if Inline is in the private part of a package
spec, the compiler can still see it when compiling the spec
separately.

The possible inline status of a subprogram compiled by a certain
compiler controlled by a certain set of switches does not add to
the knowledge of how to write calls of the subprogram properly.


>> So why
>> should inline need to be in the public view of a subprogram's spec?
>
> Because it is a part of the specification. both of them convention and inline are
> not optimisation, but code representation.

Inline gives the compiler permission to inline a subprogram,
but it does not specify anything that a programmer needs to
know in order to call the subprogram.   The calls he or she writes
will be invariably the same, no matter what the inline status
will have turned into in some executable program.


> My choice is to see this as a part of specification. Much convenient.

Writers' convenience usually is a sign of less than co-operative
software design, pardon the expression. The focus is on readers'
convenience.


>> When you c&p a subprogram's spec, when is that?
>
> When I use UML generator and wish to output subprogram specification and its properties
> (e.g. inlining or convention) be printed in one pass (line, stanza, sentence).

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.


>> Why should
>> aspects like Inline or Convention be part of the copy,
>> which is not to be the original for a reason?
>
> What is an original? Its unclear.
>
> The way that usual works fine is to add brick or remove it. Since the brick is atomic element.
>
> You are asking about how to get two bricks instead of one - a common brick and a small which is a supplement to the first one, being placed somewhere else in a private part.
> And operations you offer are - add one, and then add its extent, searching appropriate place. And otherwise - remove common, and then searching its extent somewhere else.
>
> What is the profit? It costs to much but I do not see any profit.

When I pay a programmer of a package to write a package
that I can use, I couldn't care less about whether he or she
finds it profitable or convenient to have all aspects/pragmata
in one place. I want to be able to read the spec, learn about
how to call the subprograms, and be done.

When I write just the specification and the body should be
written by someone else, then it seems rather premature
to write Inline aspects and request that they be considered
just as much specification as the parameter types or expressions
from predicate calculus stating relations between them.
OTOH, if the writers of the body decide that one of the
subprograms might be expanded inline, they can add a pragma
(or brick, as you say) as needed *without* changing the
specification of this subprogram.




> A good way is to use Inline as a configuration pragma,

Since Inline applies to program units, that won't work.
Moreover, pragma inline, if used heavily, can be counterproductive,
for example, if it makes register allocation be at odds with
the compiler's other ideas. For example, sometimes GCC's vectorizer
seems to require that a function *not* be inlined, in order to
increase overall speed of execution.

The library's developers can only disable inlining if they
removes pragma Inline / aspects, or if the tool chain can be
incapacitated in other ways.