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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9697af769c7c74cc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-04-02 12:39:00 PST Newsgroups: comp.lang.ada Path: gmd.de!ira.uka.de!yale.edu!spool.mu.edu!caen!nic.umass.edu!noc.near.net!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: Language lawyer needed Message-ID: <1993Apr2.193753.22289@inmet.camb.inmet.com> Sender: news@inmet.camb.inmet.com Nntp-Posting-Host: spock Organization: Intermetrics Inc, Cambridge MA References: <1993Apr1.215753.3147@oracorp.com> Distribution: usa Date: Fri, 2 Apr 1993 19:37:53 GMT Date: 1993-04-02T19:37:53+00:00 List-Id: In article <1993Apr1.215753.3147@oracorp.com> davidg@oracorp.com (David Guaspari) writes: >Here's a question for language lawyers. Oh boy. >Consider the following pathological program: > > procedure Q(x : integer) is > begin > declare > x : integer; -- (1) > begin > Q(x => 0); -- (2) > end; > end Q; > >My question concerns the legality of Q (forgetting about the fact that >its execution won't terminate). One way to apply chapter 8 in the >reference manual goes as follows: > > The declaration of x in (1) hides the declaration of x as a formal > parameter of Q. "Hide" in this context only means "hide from direct visibility." It is still "visible" since it is visible by selection (e.g. "Q.x" can be used as a way to name the formal parameter "x"). See RM 8.3(14): . . . A declaration is directly visible within a certain part of its immediate scope ... but excludes places where the declaration is hidden as explained below. In other words, normal "hiding" only affects direct visibility. However, just to confuse you, there are kinds of hiding that affect visibility by selection: 1) Inside a subprogram specification, all declarations with the same simple-name as that of the subprogram are hidden from *all* visibility (RM 8.3(16)). 2) Within the scope of an explicit declaration of a derivable subprogram any implicit declaration for a derived subprogram with the same profile declared immediately in the same decl. region is hidden from all visibility (RM 8.3(17)). These two are special cases. The normal hiding caused by a declaration in an inner declarative region (like your example) only affects direct visibility. By the way, we are getting rid of special case (1) in Ada 9X, since the rule is generally surprising and annoying whenever it has any effect. [If you are interested, see RM9X-8.2(2);2.0, where it is specified that the scope of an overloadable declaration doesn't start until after its profile (aka formal part, if any), thereby eliminating the problem that the rule of RM 8.3(16) (special case (1) above) was trying to solve. The problem was that before the profile, it is not clear with which other declarations the new declaration would be a homograph, making it difficult to enforce RM 8.3(17) (special case (2) above).] > Therefore, by the visibility rules, the occurrence of x in (2) has > exactly one possible meaning, namely that given by the declaration > in (1). No way, Jose'. The identifier preceding "=>" in a parameter association does not use "direct visibility" but rather "visibility by selection" (see RM 8.3(6,11)). The declaration at (1) does not hide the declaration of the formal parameter X for the purposes of visibility by selection. > However, the declaration in (1) is not visible by selection at the > point at which x occurs in (2). This statement is false. Which paragraph in RM 8.3 made you think it was true? Curious revisers of 8.3 want to know... > Therefore the call in (2) is illegal. No, the call in (2) is legal. >One the other hand, at least one compiler (Telesoft) thinks that Q is >legal, an outcome that seems a reasonable enough outcome to common >sense untutored by the reference manual. So, what *is* the right >answer, and how do we get it from the RM? Hopefully the above references explain the rule. By the way, in RM9X we use "selector_name" wherever visibility by selection is relevant, and "direct_name" wherever direct visibility is relevant. In particular, the identifier preceding "=>" is a selector_name, not a direct_name. Hopefully this change will make the BNF more suggestive of the semantics. >- David Guaspari > davidg@oracorp.com S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138