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

["Vasiliy Molostov" <molostoff@gmail.com>]

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.

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

Caller should be possible to establish any property to link this  
subprogram to its own image (link it from a library or from a standalone  
compiled module).
If not - linking is not possible.


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

Unclear, or I cannot see any relation to convention/inlining.
What are you about? Rook gambits are tied?

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

The question was - WHY? And for what benefit?

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

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.

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

> 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? 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.
The question was - why you have named 'convention' as one of optimizations?

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

I suppose as you pay - you dont write them. Probably your way - is to pay  
for all
the program (and related subprograms) entirely, without making things  
stressed
for people (or tools) with which you dont share their convenience.

Buy ready to use thing - its much less nervous!

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

Indeed. Premature. If you design is weak and there is nothing to supply it  
is indeed premature to write aspects at all.

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

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

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

How about Q&A team with their set of tests that meet some kind of such a  
small extention brick at testing stage?

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

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

Do you plan to add here also excerpts from Yellow Pages? I have a copy,  
btw.

The question is still open: Why You have insist that convention is an  
optimisation?
-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/