From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 11 Sep 91 19:24:03 GMT From: aio!gwharvey@eos.arc.nasa.gov (Greg Harvey) Subject: Re: why are these unknown identifiers? Message-ID: List-Id: In <9109101616.aa26718@PARIS.ICS.UCI.EDU> jduarte@liege.ICS.UCI.EDU (Jose Duart e) writes: >----------------------------------------- >package X is > type DIRECTIONS is (UP,DOWN,LEFT,RIGHT); >end X; >----------------------------------------- >with X; >package Y is > subtype DIRECTIONS is X.DIRECTIONS; >end Y; >----------------------------------------- >with TEXT_IO; >use TEXT_IO; >with Y; >procedure BUG is >V1 : Y.Directions := Y.UP; -- Y.UP is unknown >V2 : Y.Directions := Y.DOWN; -- Y.DOWN is unknown >begin > null; >end BUG; >Can someone tell me why "Y.UP" and "Y.DOWN" are unknown identifiers >within the procedure BUG? I have to "with X" and then assign X.UP >and X.DOWN to V1 and V2 in order to compile this. Why is this the case? >Is this an Ada pecularity or a compiler bug? This is a little involved, so I'll give you my take on why, then give some Ada LRM references that support what you've discovered. My take is that Ada has several `features' which are strongly implementation specific. in order for what you have done to work, the compiler would have to have access to the lexical scope where each enum literal is declared. The subtype definition does not redeclare the literal, therefore, the literal is not in scope if only Y is withed. The advantage is that X does not have to be withed UNLESS access is needed to this specific lexical information. Now, to Ada LRM references that support this conclusion: 3.5.1 Enumeration Types Paragraph 3--Each enumeration literal specification is the declaration of the corresponding literal: this declaration is the equivalent... Our interpretation--the where if declaration is limited to the place where the literal actually occurs. 3.3.2 Subtype Declarations Paragraph 1--A subtype declaration declares a subtype. Our interpretation--This is interpreted strictly. The subtype does not include the definition of the members of the enumeration, in this example. 8.2 Scope of Declaration Paragraph 2-8--The scope of a declaration that occurs immediately within a declarative region extends from the beginning of the declaration to the end of the declarative region; this part of the scope of a declaration is called the immediate scope. Furthermore, for any of the declarations listed below, the scope of the declaration extends beyond the immediate scope: (a) A declaration that occurs immediately within the visible part of a package declaration. (b) An entry declaration. (c) A component declaration. (d) A discriminant declaration. (e) A parameter specification. (f) A generic parameter declaration. Our interpretation--The scope of declaration for is limited to the immediate declarative region or is extended under special circumstances. Because our item (or object) falls into (c), it can be given an extended scope of declaration. The rule for that is given in paragraph 9 & 11: In each of these cases, the given declaration occurs immediately within some enclosing declaration, and the scope of the given declaration extends to the end of the scope of the enclosing declaration. [paragraph 10 talks about subprogram declarations] Note: The above scope rules apply to all forms of declaration defined by Section 3.1; in particular, they apply also to implicit declarations. Rule (a) applies to a package declaration and thus not to the package specification of a generic declaration. [NOTICE THIS:] For nested declarations, the rules (a) through (f) apply at each level. For example, if a task unit is declared in the visible part of a package, the scope of an entry of the task unit extends to the end of the scope of the task unit, that is, to the end of the scope of the enclosing package. More interpretation--the scope of a declaration is limited to a region of declaration or the enclosing region of declaration if nested. To find out HOW this works with packages, we need to look at visibility rules. 8.3 Visibility Paragraph 2--For each identifier and at each place in the text, the visibility rules determine a set of declarations (with this identifier) that define possible meanings of an occurrence of the identifier. A declaration is said to be visible at a given place in the text when, according to the visibility rules, the declaration defines a possible meaning of this occurrence. ... Our intepretation--The actual literal is declared in X. The scope of that declaration is limited to X and packages that extend the visibility of that scope properly (through with, use, and renames.) Your procedure extends the scope of declaration of Y to include the procedure, but never includes the declaration of the actual literal. This allows you to reference the subtype, but not to reference specific elements of the enumeration. Checking this out--If this is true, then the subtype is limited to the enumeration in values it can take, but the actual values only are visible if the declaration of the enum literal, package X, is withed. This agrees with what Jose found. Of further interest: try replacing the V1 and V2 declarations with this: V1: Y.Directions := Y.Directions'Value("UP"); V2: Y.Directions := Y.Directions'Value("Aaarf"); Both of these lines compile fine on the Rational R1000, but the second one gives a Constraint_Error when executed. >Thanks! >JOSE DUARTE Douglas Surber prepared the brief on this...btw. I hope I adequately explained his argument. -- If you get the impression I'm not qualified to speak for my company, it's because I ain't, I can't, I don't, I won't, and I don'wanna. Greg Harvey --Temporarily without mail service Lockheed, Houston Texas --Hope to have a PSCNI route soon!