Re: Enumeration literal visibility and use type

[bralick@seas.smu.edu (William Bralick)]

In article <6kejt5$75u@gcsin3.geccs.gecm.com|,
John McCabe  <jgm@hayling.cwmbran.gecm.com| wrote:
|bralick@seas.smu.edu (William Bralick) wrote:
|
|>package doodah is
|>
|>  type state_value_type is (state0, state1, state2, state_etc);
|>
|>  -- and just to make things interesting, let's create a useful message
|>
|>  type useful_message is record
|>    state_stuff : state_value_type;
|>    other_stuff : natural;
|>  end record;
|>
|>end doodah;
|
|There is no "cool_type". There is "state_value_type" and 
|"useful_message", so you're "use type doodah.cool_type" will never work 
|for a start.

Hmm ... so much for changing horses (examples) in midstream.  Yes, I 
obviously intended "use type doodah.state_value_type" where I wrote 
"use type doodah.cool_type".  Mea culpa.

|>For some reason that I have yet to fathom, I had convinced myself 
|>that "use type" would give immediate visibility of the enumerals in 
|>doodah.cool_type.  I am now convinced that it doesn't (though I am
         ^^^^^^^^^
         state_value_type

|>ready to argue that it _should_).
|
|Despite the obvious error, the "use type" clause is designed to provide 
|visibility to the OPERATORS of the type, NOT the type itself so the 
|behaviour you are seeing is correct.

Yes ... and I had understood that visibility of the type name was still
restricted (one would always need to write doodah.state_value_type), but
I was convinced that the enumerals themselves would be visible to avoid 
(1) the use of the "use clause" or (2) defining a series of named constants.
The latter work-around looks disturbingly like the function renames that 
we were avoiding with the use type clause.

So once again, I am merely asking for a reference to some documentation
that might describe _why_ OPERATORS only were made visible and in particular
why enumerals were left in the (somewhat) clumsy Ada'83 form.  Perhaps this
was never even considered ... that would be important to know, too.

Anybody? 

Best regards,

-- 
Will Bralick        ............_/......._/__/..._/.......__/..._____/
                       ........._/....._/_/._/.._/......_/._/.._/..._/
        ........................._/..._/______/._/...________/._/___/
                         ........._/._/_/....._/_/...._/....._/_/.._/