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,4885c546f6ddc77a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.220.230 with SMTP id pz6mr18112885pbc.3.1340751208688; Tue, 26 Jun 2012 15:53:28 -0700 (PDT) MIME-Version: 1.0 Path: l9ni23555pbj.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Dynamic accessibility Date: Tue, 26 Jun 2012 17:53:21 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <192bee3d-c0d4-421d-b5f6-676bce2a38db@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1340751206 18184 69.95.181.76 (26 Jun 2012 22:53:26 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 26 Jun 2012 22:53:26 +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-06-26T17:53:21-05:00 List-Id: wrote in message news:ff9d9547-a61f-454e-8804-1e4f8018dac7@googlegroups.com... On Friday, June 22, 2012 4:03:35 PM UTC-4, Randy Brukardt wrote: >> Note that "aliased" parameters help a bit here (they're >> guaranteed to live as long as the result of the function call, which is a >> bit longer than a "normal" parameter). > >Since there is an active topic about it, what exactly is the distinction >between explicitly aliased > parameters for functions and those of procedures? The way I read the LRM > 6.1 (and from what > I glean elsewhere), either a procedure or a function can have an E.A.P, > and that your mention > of 'function call' is assumed to mean 'subprogram call' in general. The accessibility of an explicitly aliased parameter for a procedure is the same as that for any other parameter of a procedure. The special case exists for the result of a function call, and thus it doesn't make any sense for it to apply to procedures (which have no result). >However, the rules in 3.10.2 also vauge. Oh no, you've looked into the "Heart of Darkness"! No one ever returns from there! :-) > 7/3 says "Other than for an explicitly aliased parameter...", so that > parameter rule does > not apply to EAPS of either functions or procedures. 13.3/3 deals > specifically with > functions, as does 19.2/3, and so nothing seems to explicitly apply to the > EAP of a procedure. > > Is there some other rule that applies by default, or is 'function' assumed > to mean both > (which I don't recall happening elsewher in the LRM, but I of course am > not that familiar with it). It does look like a bug. But: No one understands 3.10.2, it literally takes hours to figure out any question in there (which is why it's nicknamed the "Heart of Darkness"). My recollection is that 3.10.2(7/3) is not formally needed and thus we used a sloppy wording. Moreover, that sentence is intended only to describe dynamic accessibility, which (hopefully) never will apply to an explicitly aliased paramter. Anyway, I'm not going to even think about spending the hours to figure out if you are right or if it is covered some other way. In any case, 3.10.2 is one giant bug (plus it probably can't actually be implemented). So ask me in 2018 when we're getting the next revision of Ada underway. Hopefully by then this will all be gone. :-) Randy. -sb