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: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ChineseT,UTF8 Received: by 10.66.76.130 with SMTP id k2mr1439356paw.16.1344848751087; Mon, 13 Aug 2012 02:05:51 -0700 (PDT) Path: p10ni50916232pbh.1!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!novia!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!80.86.168.138.MISMATCH!news-feed.eu.lambdanet.net!news.bcc.de!newsfeeder.ewetel.de!ecngs!feeder2.ecngs.de!78.46.240.70.MISMATCH!weretis.net!feeder4.news.weretis.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 06 Aug 2012 23:52:34 +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> In-Reply-To: Message-ID: <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 06 Aug 2012 23:52:34 CEST NNTP-Posting-Host: 6c3509fa.newsspool1.arcor-online.net X-Trace: DXC=UMNL^8e_BY^cHPTNZh_e7Qic==]BZ:af^4Fo<]lROoRQnkgeX?EC@@PV59:cPRXS:VPCY\c7>ejVXGjA^1]:>gjRe21S?PM?=O_ X-Complaints-To: usenet-abuse@arcor.de X-Received-Bytes: 7525 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: 2012-08-06T23:52:34+02:00 List-Id: On 06.08.12 23:01, Vasiliy Molostov wrote: > Georg Bauhaus писал(а) в своём письме Mon, 06 Aug 2012 21:58:25 +0400: > >> On 06.08.12 17:50, Vasiliy Molostov wrote: >>> Robert A Duff писал(а) в своём письме Mon, 06 >>> Aug 2012 18:33:42 +0400: >>> >>>> "Randy Brukardt" 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.