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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no 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,UTF8 Received: by 10.66.74.102 with SMTP id s6mr1810197pav.21.1344332021545; Tue, 07 Aug 2012 02:33:41 -0700 (PDT) Path: c10ni92262pbw.0!nntp.google.com!news2.google.com!news4.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!94.232.116.11.MISMATCH!feed.xsnews.nl!border-1.ams.xsnews.nl!feeder1-1.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 07 Aug 2012 11:33:21 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Message-ID: <5020e0e1$0$6570$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 Aug 2012 11:33:21 CEST NNTP-Posting-Host: 5d179356.newsspool3.arcor-online.net X-Trace: DXC=4`nY74]hjfM0YVY]kmLTlDMcF=Q^Z^V3H4Fo<]lROoRA8kFejVHGjA^1]:>gjB8AQ=g==e[MC X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: 2012-08-07T11:33:21+02:00 List-Id: On 07.08.12 01:09, Vasiliy Molostov wrote: > Georg Bauhaus писал(а) в своём письме 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.