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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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,ASCII-7-bit Received: by 10.181.11.234 with SMTP id el10mr885794wid.2.1344222587762; Sun, 05 Aug 2012 20:09:47 -0700 (PDT) MIME-Version: 1.0 Path: q11ni64616001wiw.1!nntp.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Sun, 5 Aug 2012 22:09:41 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1344222585 27820 69.95.181.76 (6 Aug 2012 03:09:45 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 6 Aug 2012 03:09:45 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-08-05T22:09:41-05:00 List-Id: "Robert A Duff" wrote in message news:wcc4noj4zof.fsf@shell01.TheWorld.com... > Adam Beneschan writes: > >> # I don't believe that either Inline or Import should be hidden in the >> private >> # part, because both have (subtle) semantic effects that potentially >> break >> # privacy. In particular, inline adds dependencies that might make >> linking a >> # program impossible. > > I don't think that's right. Inline doesn't add dependencies. > >>...(I don't think inline should be allowed to do that, >> # either, but that's the way it is.) > > I don't think inline should be allowed to do that, either > -- fortunately, that's not the way it is. ;-) > > If you (Randy) don't agree, please quote chapter&verse. We had this discussion on the ARG list ()last fall, I think), and we pretty much agreed that it could. (I don't think you ever agreed, but there's plenty of evidence in the RM - I'm not going to waste my time looking it up again. You didn't believe the evidence that was presented last time, but you were clearly wrong then and you still are. :-) Certainly with a "conventional" compiler like Janus/Ada, a body can be out of sync with a specification, and inline creates a dependence on the body that doesn't exist before - that's guarenteed to cause problems. > I just tried the following example, which has mutually-recursive > inlining, and gnat didn't have any trouble compiling it or > linking it. I think that's required -- a compiler would be > wrong to say this example is illegal. It's not illegal, it fails to link. That's pretty different! (Everyone else: sorry, this is language-lawyer talk.) Anyway, inline is a permission, and a compiler can ignore it. But if it doesn't ignore it, it causes additional dependences. In any case, I don't see why you think it is relevant when it clearly depends on the compiler. (GNAT never pre-compiles specifications, so I don't think you could ever see one of these dependencies in a way that prevented linking. But it's easy in other compilers) Randy.