Re: why are these unknown identifiers?

[aio!gwharvey@eos.arc.nasa.gov (Greg Harvey)]

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 <italics on>immediate scope<italics off>.
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!