why are these unknown identifiers?

why are these unknown identifiers?

[Jose Duarte]

-----------------------------------------
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?


Thanks!
JOSE DUARTE

Re: why are these unknown identifiers?

[agate!spool.mu.edu!news.cs.indiana.edu!arizona.edu!east.pima.edu!rharwood]

In article <9109101616.aa26718@PARIS.ICS.UCI.EDU>, jduarte@liege.ICS.UCI.EDU
(Jose Duarte) 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? 

To answer your question, I propose that you temporarily change package Y to:
    with X;
    package Y is
 	type DIRECTIONS is new X.DIRECTIONS;
    end Y;
NOW you don't need X... the reason is that the IDENTIFIERS (for enumerated
types) and the OPERATORS (for virtually all non-private types) are considered
to be "declared" at the same scope of the TYPE declaration... and a subtype
does NOT declare a new type.  Therefore the SUBTYPE Y.DIRECTIONS is heavily
dependent on the declaration of X.DIRECTIONS... while a TYPE Y.DIRECTIONS
establishes the identifiers and operations inside the scope of Y.

I hope I've communicated this well.
Ray
-----
Ray Harwood           |Data Basix           |Associate Faculty,    
Voice: (602)721-1988  |PO Box 18324         |   Pima Community College
FAX:   (602)721-7240  |Tucson, AZ 85731     |Instructor in Ada and Pascal
CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu

Re: why are these unknown identifiers?

[Robert I. Eachus]

In article <9109101616.aa26718@PARIS.ICS.UCI.EDU> jduarte@liege.ICS.UCI.EDU (Jo
se Duarte) 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?

-- You could say it is an Ada pecularity, because Ada is the only
-- language with all the features necessary to run into it.  A type
-- declaration derives operations for the parent type, but a subtype
-- does not.  Therefore there is no function UP return DIRECTIONS in
-- package Y.  If you want to be able to refer to Y.UP you should say
-- either:

   with X;
   package Y is 

     type DIRECTIONS is new X.DIRECTIONS;
     -- derived functions declared here.

   end Y;

-- or:

   with X;
   package Y is

     subtype DIRECTIONS is X.DIRECTIONS;
     function UP return DIRECTIONS renames X.UP;
     function DOWN return DIRECTIONS renames X.DOWN;
     function LEFT return DIRECTIONS renames X.LEFT;
     function RIGHT return DIRECTIONS renames X.RIGHT;

   end Y;

-- The first approach will require explicit conversions when trying to
-- assign values of type X.DIRECTIONS to variables of type
-- Y.DIRECTIONS and vice-versa.  (When designing Ada, this was thought
-- to be a GOOD thing.)  In the second case cross assignments are not
-- a problem but saying use X; use Y; will result in neither
-- declaration of UP being directly visible.

					Have fun,

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: why are these unknown identifiers?

[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! 

Re: why are these unknown identifiers?

[csus.edu!wupost!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uv]

In article <9109101616.aa26718@PARIS.ICS.UCI.EDU> jduarte@liege.ICS.UCI.EDU (Jo
se Duarte) writes:
> -----------------------------------------
> package X is
> 	type DIRECTIONS is (UP,DOWN,LEFT,RIGHT);
> end X;
> -----------------------------------------
> with X;
> package Y is
> 	subtype DIRECTIONS is X.DIRECTIONS;

replace the subtype declaration with a derived type:
    type Directions is new X.Directions;
 
> end Y;
> -----------------------------------------

remove extraneous with of 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?
> 
> 
> Thanks!
> JOSE DUARTE

Make the above change from subtype to derived type to
accomplish what you were trying (I didn't see any reason
to with Text_IO).  Of course, you will find other differences
which you may not like, such as the need for explicit
type conversions.

Now you can study the differences between subtypes and
derived types (I have never been able to do better than
the LRM, and will let others "explain" the differences).

Re: why are these unknown identifiers?

[Dave Williamson]

Jose Duarte writes:
>package X is
>    type DIRECTIONS is (UP, DOWN,...
>end X;
>with X;
>package Y is
>    subtype DIRECTIONS is X.DIRECTIONS;
>end Y;
>with Y;
>procedure BUG is
>V1 : Y.Directions := Y.UP;
>.....
>Can someone tell me why "Y.UP" and "Y.DOWN" are unknown identifiers....

Looks right to me.  Y.UP and Y.DOWN don't exist.  What you probably mean
to do is declare a dervied type as follows:

with X;
package Y is
    type DIRECTIONS is new X.DIRECTIONS;
end Y;

Dave Williamson
Software Kinetics Ltd.
Ottawa, Canada
williams@crc.sofkin.ca

Re: why are these unknown identifiers?

[Mr. D. Harter]

jduarte@liege.ICS.UCI.EDU (Jose Duarte) writes:
> -----------------------------------------
> with X;
> package Y is
> 
> 	subtype DIRECTIONS is X.DIRECTIONS;
> 
> end Y;
> -----------------------------------------
.
.
.
> 
> V1 : Y.Directions := Y.UP;    -- Y.UP is unknown
> V2 : Y.Directions := Y.DOWN;  -- Y.DOWN is unknown
> 

My Ada's a bit rusty, too much exposer to C, but is your not going to use
the base type of Y.DIRECTIONS at any point try this:

with X;
package Y is

	type DIRECTIONS renames X.DIRECTIONS;

end Y;

No flames if I'm wrong please.
-- 
Darren Harter                                  | Computer Science Department
					       | University of Liverpool
ARPA/Internet:  darren@compsci.liverpool.ac.uk | PO Box 147
JANET:          darren@uk.ac.liverpool.compsci | Liverpool L69 3BX

Re: why are these unknown identifiers?

[& Wise]

In article <1991Sep17.145807.634@and.cs.liv.ac.uk> darren@uxa.liv.ac.uk (Mr. D.
 Harter) writes:
   My Ada's a bit rusty, too much exposer to C, but is your not going to use
   the base type of Y.DIRECTIONS at any point try this:

   with X;
   package Y is

           type DIRECTIONS renames X.DIRECTIONS;

   end Y;

   No flames if I'm wrong please.

No flames.  Just the simple observation that renames clauses do not
work for type declarations.  You must use subtypes for this.

        /s
--
Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory
/\/\/\/\/\/\/\/\/\/\/\/\/\/\ WISE@CS.UMASS.EDU /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\