Enumeration literal visibility and use type

Enumeration literal visibility and use type

[William Bralick]

Greetings!

By now I have convinced myself that the following does not work as I had 
hoped:

-- we are provided the following package and required to use it to 
-- interface with other subsystems

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;

---

with doodah;
procedure test is

   use type doodah.cool_type;

   a_cool_message : useful_message;

begin

   a_cool_message.state_stuff := state0;  -- SIRENS WAIL, LIGHTS FLASH
                                          -- COMPILER WANTS: 
                                          -- doodah.state0

   ...

end test;

---

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
ready to argue that it _should_).

Because sharing this information with my other team members will require
that I eat more than a little crow ;-), I am looking for a pointer to 
any information (chapter and verse in the rationale, an AI, anything ...) 
that would explain _why_ Ada95 does not provide immediate visibility to 
enumeration types that have been the object of a "use type" clause.

Thanks and best regards,

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

Re: Enumeration literal visibility and use type

[John McCabe]

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.

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

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
=====================================================================

Re: Enumeration literal visibility and use type

[David C. Hoos, Sr.]

John McCabe wrote in message <6kejt5$75u@gcsin3.geccs.gecm.com>...
>bralick@seas.smu.edu (William Bralick) wrote:
>
>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.
>
John is correct.  The only way I've found to make the literals visible
(without
a context clause "use doodah;") is in the units requiring visibility is to
declare:

state_0 : constant doodah.state_value_type := doodah.state_0;
.
.
.
state_etc : constant doodah.state_value_type := doodah.state_etc;
Anyone have a better way?

David C. Hoos, Sr.

Re: Enumeration literal visibility and use type

[Matthew Heaney]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> >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.
> >
> John is correct.  The only way I've found to make the literals visible
> (without
> a context clause "use doodah;") is in the units requiring visibility is to
> declare:
> 
> state_0 : constant doodah.state_value_type := doodah.state_0;
> .
> .
> .
> state_etc : constant doodah.state_value_type := doodah.state_etc;
> Anyone have a better way?


Yes.  Do a use immediately after declaring the object:

declare
   State : Doodah.State_Value_Type;
   use Doodah;
begin
   <literals are now directly visible>
   State := State_0;
end;

The idea is that you want to be able to trace an entity back to the
source.  Since you've stated explicitly that State_Value_Type is
declared in Doodah, there is high probability that State_0 is declared
there too.

Matt

Re: Enumeration literal visibility and use type

[John McCabe]

Matthew Heaney <matthew_heaney@acm.org> wrote:
>> Anyone have a better way?
>
>
>Yes.  Do a use immediately after declaring the object:
>
>declare
>   State : Doodah.State_Value_Type;
>   use Doodah;
>begin
>   <literals are now directly visible>
>   State := State_0;
>end;
>
>The idea is that you want to be able to trace an entity back to the
>source.  Since you've stated explicitly that State_Value_Type is
>declared in Doodah, there is high probability that State_0 is declared
>there too.

But here you are still bringing far more than State_Value_Type and its 
operators into scope in the block which is what William is trying to 
avoid.

If the block was simple then that could be a way to do it, and I have 
done it myself that way before. But if it is complicated, the declare 
section could easily get lost in the noise in a printout, leaving it only 
very slightly clearer than "use"ing doodah at the outer level.

-- 
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[John English]

David C. Hoos, Sr. (david.c.hoos.sr@ada95.com) wrote:

: John McCabe wrote in message <6kejt5$75u@gcsin3.geccs.gecm.com>...
: John is correct.  The only way I've found to make the literals visible
: (without
: a context clause "use doodah;") is in the units requiring visibility is to
: declare:

: state_0 : constant doodah.state_value_type := doodah.state_0;
: .
: .
: .
: state_etc : constant doodah.state_value_type := doodah.state_etc;
: Anyone have a better way?

Dunno about "better", but I can do "different"... ;-)

function state_0 return doodah.state_value_type renames doodah.state_0;
-- etc. etc.

(but of course I'd use Capitalised_Identifiers :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Enumeration literal visibility and use type

[Ray Blaak]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
>John is correct.  The only way I've found to make the literals visible
>(without a context clause "use doodah;") is in the units requiring
>visibility is to declare:
>state_0 : constant doodah.state_value_type := doodah.state_0;
>Anyone have a better way?

I like doing:

  package doodah is
    package State is
      type Value is (state0, state1, ...);
    end State;
    ...
  end doodah;

  with doodah;
  procedure Main is
    use doodah.State;
    cool : doodah.State.Value := state0;
  begin
  end Main;

Another approach, especially when you only need the literals in a case
statement, is to do:

  package doodah is
    type state_value is (state0, ...);
    ...
  end doodah;

  with doodah;
  procedure Report_State(The_State : in doodah.state_value) is
    type states is new doodah.state_value; -- literals are now in scope
  begin
    case states(The_State) is
    when state0 => ...;
    when state1 => ...;
    ...
    end case;
  end Report_State;

Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Enumeration literal visibility and use type

[John McCabe]

(Ray Blaak) wrote:
>
>The Rhythm is around me,
>The Rhythm has control.
>The Rhythm is inside me,
>The Rhythm has my soul.

He was brilliant then - I went to see him at the Glasgow Apollo that 
year.

-- 
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk> <- use this for emailblaak@infomatch.com 
=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[John McCabe]

OOPS
That was meant to be email only but I forgot to take the newsgroup name 
out of the header!

Netscape 1.22 - What a newsreader - NOT!

Sorry

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[Robert Dewar]

<<state_0 : constant doodah.state_value_type := doodah.state_0;
.
.
.
state_etc : constant doodah.state_value_type := doodah.state_etc;
Anyone have a better way?
>>

Sure! Use a normal use clause on the package. If you like isolate
the type in its own package, so the scope of the use clause is
limited to the type.

Re: Enumeration literal visibility and use type

[Matthew Heaney]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Anyone have a better way?
> >>
> 
> Sure! Use a normal use clause on the package. If you like isolate
> the type in its own package, so the scope of the use clause is
> limited to the type.

Yes!  This is the simplest and best technique to use.

Re: Enumeration literal visibility and use type

[Roger Racine]

In article <6kej65$dnh$1@hermes.seas.smu.edu> bralick@seas.smu.edu (William 
Bralick) writes:
>By now I have convinced myself that the following does not work as I had 
>hoped:

>-- we are provided the following package and required to use it to 
>-- interface with other subsystems

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

>---

>with doodah;
>procedure test is

>   use type doodah.cool_type;

>   a_cool_message : useful_message;

>begin

>   a_cool_message.state_stuff := state0;  -- SIRENS WAIL, LIGHTS FLASH
>                                          -- COMPILER WANTS: 
>                                          -- doodah.state0

>   ...

>end test;

>---

>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
>ready to argue that it _should_).

Section 8.4 of the Ada RM:

"a use_type_clause achieves direct visibility of the 
primitive operators of a type."

Enumeration literals are not operators.

Roger Racine

Re: Enumeration literal visibility and use type

[Matthew Heaney]

bralick@seas.smu.edu (William Bralick) writes:

> 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
> ready to argue that it _should_).
> 
> Because sharing this information with my other team members will require
> that I eat more than a little crow ;-), I am looking for a pointer to 
> any information (chapter and verse in the rationale, an AI, anything ...) 
> that would explain _why_ Ada95 does not provide immediate visibility to 
> enumeration types that have been the object of a "use type" clause.

No, use type will NOT give you direct visibility to the enumeration literals.

I helps to understand the type model wrt to enumeration types.  In Ada,
an enumeration literal is modeled as a "primitive operation" of the
type.  Given this declaration,

type T is (E1, E2, E3);

it's as if it were declared like this:

type T;
function E1 return T;
function E2 return T;
function E3 return T;

The reason for this is that it allows different enumeration types in the
same scope to have the same values for literals, ie

type T2 is (E2, E3, E4);

O1 : T1 := E2;
O2 : T2 := E2;

The model is that E2 is a parameterless function returning a value of
the type.  Since each type is different, each "function" is different,
and so there is no confusion about what E2 means.  The usual name
resolution rules apply.

The issue is that "use type" only gives you direct visibility to the
predefined "operators" of a type; it does not give you direct visibility
to the predefined "operations" of a type.  Enumeration literals are
operations, not operators, and so aren't made directly visible by "use
type."

Does that explain it?

Matt

P.S.  Here's another example to illustrate how enumeration types work.
Given this declaration, 

generic
   type T is private; 
   function F return T;
package GP is ...;

I can instantiate it using an enumeration literal, passing it as the
generic actual "function":

package P is new GP (T, E2);

Pretty cool, eh?

Re: Enumeration literal visibility and use type

[Mats Weber]

> The issue is that "use type" only gives you direct visibility to the
> predefined "operators" of a type; it does not give you direct visibility
  ^^^^^^^^^^ primitive
> to the predefined "operations" of a type.  Enumeration literals are
> operations, not operators, and so aren't made directly visible by "use
> type."

Re: Enumeration literal visibility and use type

[William Bralick]

In article <m3btsk8xoa.fsf@mheaney.ni.net>,
Matthew Heaney  <matthew_heaney@acm.org> wrote:
|
|No, use type will NOT give you direct visibility to the enumeration literals.

Acknowledged.

|...
|The issue is that "use type" only gives you direct visibility to the
|predefined "operators" of a type; it does not give you direct visibility
|to the predefined "operations" of a type.  Enumeration literals are
|operations, not operators, and so aren't made directly visible by "use
|type."

I think that this is the key point where my confusion arose.  

I recall understanding the concept of enumerals being parameterless 
functions and I guess that I conflated them with the concept of 
"operators" perhaps because I was simultaneously dealing with the 
definition of "primitive operations" and "primitive subprograms" 
which, of course, include operators ...

Oh, well.

|Does that explain it?

Yes, thanks.  You have all been most helpful ...

Best regards,

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

Re: Enumeration literal visibility and use type

[John McCabe]

Matthew Heaney <matthew_heaney@acm.org> wrote:
>
>P.S.  Here's another example to illustrate how enumeration types work.
>Given this declaration, 
>
<..snip..>
>
>Pretty cool, eh?

That's a matter of opinion (although it certainly explains John English's 
comment which I didn't originally understand). That's a bit like saying 
the conditional statement:

x = (y>z) ? z : y;

makes sense if you ask me!

-- 
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[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        ............_/......._/__/..._/.......__/..._____/
                       ........._/....._/_/._/.._/......_/._/.._/..._/
        ........................._/..._/______/._/...________/._/___/
                         ........._/._/_/....._/_/...._/....._/_/.._/

Re: Enumeration literal visibility and use type

[Fergus Henderson]

bralick@seas.smu.edu (William Bralick) writes:

>John McCabe  <jgm@hayling.cwmbran.gecm.com| wrote:
>|... 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.

What's wrong with (3) just using explicit module qualifiers?

>So once again, I am merely asking for a reference to some documentation
>that might describe _why_ OPERATORS only were made visible

Because explicit module qualifiers on OPERATORS look very ugly.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Enumeration literal visibility and use type

[John McCabe]

fjh@cs.mu.oz.au (Fergus Henderson) wrote:
>>So once again, I am merely asking for a reference to some documentation
>>that might describe _why_ OPERATORS only were made visible
>
>Because explicit module qualifiers on OPERATORS look very ugly.

And explicit module qualifiers on enumeration literals don't?

-- 
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[Robert Dewar]

John McCabe says

<<And explicit module qualifiers on enumeration literals don't?
>>

If you think that explicit module qualifiers on identifiers are ugly, then
you definitely want to consider using a real "use" package clause.

Basically what is going on with use type is that there are a significant
number of people who don't mind writing, or even prefer to write:

   package_name.identifier;

and of course enumeration literals are just a special case of identifiers.
But they draw the line at

   package_name."+" (x,y);

Basically the issue here is that people want to know the package where
something comes from at a glance, and hence don't like use package clauses,
but their desire to see the package where something comes from at a glance
is not strong enough to overcome their disgust at having to go to the ugly
prefix notation for binary operators. It's just a matter of trading off
syntactic ugliness vs explicit qualification.

I always have trouble understanding this distinction, but I *SURELY* cannot
understand that someone would not mind writing:


	x := red;

where red is an enuemration literal, but would not want to write

        x := colorget;

where colorget is some other function than an enumeration literal. To 
want to qualify in the second case:

        x := pkg.colorget;

but to object to

        x := pkg.red;

seems very inconsistent to me. I do understand the use type argument, but
surely to make it apply to enumeration literals and not other primitive
operations would be very odd indeed.

Re: Enumeration literal visibility and use type

[John McCabe]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>John McCabe says
>
><<And explicit module qualifiers on enumeration literals don't?
>>>
>
>If you think that explicit module qualifiers on identifiers are ugly, 
>then you definitely want to consider using a real "use" package clause.

I have no real problem with that personally, and have done so on various 
occasions although obviously I have tried to restrict the scope of the 
use (package) clause as much as possible. 

>Basically what is going on with use type is that there are a significant
>number of people who don't mind writing, or even prefer to write:
>
>   package_name.identifier;
>
>and of course enumeration literals are just a special case of
>identifiers. But they draw the line at
>
>   package_name."+" (x,y);

I believe it's simply to do with people's expectations.

Naturally (well.. you know what I mean) we expect addition of 2 values to 
be represented by x + y, and this is true of most High Level Languages 
that I'm aware of, and C. Therefore it simply appears natural to prefer 
to see x + y rather than package_name."+"(x,y). (Note: I believe that 
both the package name and the ""s tend to distract the reader from the 
meaning in these cases).

If Ada didn't allow the use of operators in this way, we would probably 
have to write a new function say package_name.sum(x,y) to perform this 
operation, but which wouldn't look anywhere near as blatantly unnatural.

>I always have trouble understanding this distinction, but I *SURELY* 

<..snip..>

>seems very inconsistent to me. I do understand the use type argument, 
>but surely to make it apply to enumeration literals and not other
>primitive operations would be very odd indeed.

I'm not sure what you mean here. Isn't it the primitive operations that 
it already applies to? If so, there is no suggestion of it being applied 
to only enumeration literals and not to the primitive operations. As far 
as I understand it, the question is why doesn't it apply to both?

-- 
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[Robert Dewar]

John McCabe said

<<>seems very inconsistent to me. I do understand the use type argument,
>but surely to make it apply to enumeration literals and not other
>primitive operations would be very odd indeed.

I'm not sure what you mean here. Isn't it the primitive operations that
it already applies to? If so, there is no suggestion of it being applied
to only enumeration literals and not to the primitive operations. As far
as I understand it, the question is why doesn't it apply to both?
>>

You are getting confused by the terminology. Primitive operations refers
to all functions and procedures defined with a parameter or return type
of the type. You read "operators" for operations. use type refers ONLY
to operators, not to all primitive operations.

Re: Enumeration literal visibility and use type

[John McCabe]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>John McCabe said

Blah blah ... primitive operations...

>
>You are getting confused by the terminology.

You are quite correct. Thank you for clearing up my confusion.

-- 
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[Thomas Hood]

John McCabe wrote:
> 
> dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> >John McCabe says

<snip>

> >
> >   package_name."+" (x,y);
> 
> I believe it's simply to do with people's expectations.
> 
> Naturally (well.. you know what I mean) we expect addition of 2 values to
> be represented by x + y, and this is true of most High Level Languages
> that I'm aware of, and C. Therefore it simply appears natural to prefer
> to see x + y rather than package_name."+"(x,y). (Note: I believe that
> both the package name and the ""s tend to distract the reader from the
> meaning in these cases).

<snip>

My usual Ada83 way around this was to import the operator using a
renames clause.
i.e.  function "+"(l,r : my_pkg.my_type) return my_pkg.my_type renames
my_pkg."+";

This allows the infix use of the binary operator.  It is still clumsy
and not very pretty but it sure makes the body of the code read better.

Thomas Hood
thomas@ifn.com
thomas@yachtrace.net

Re: Enumeration literal visibility and use type

[Robert Dewar]

Thomas said

<<My usual Ada83 way around this was to import the operator using a
renames clause.
i.e.  function "+"(l,r : my_pkg.my_type) return my_pkg.my_type renames
my_pkg."+";

This allows the infix use of the binary operator.  It is still clumsy
and not very pretty but it sure makes the body of the code read better.
>>


You and x zillion other Ada 83 programmers, this is indeed an absolutely
standard technique among those who do not like to use "use".

And it is EXACTLY this stuff that "use type" was designed to consign to
the rubbish bin!

Re: Enumeration literal visibility and use type

[Peter Amey]

John McCabe wrote:
> 
> fjh@cs.mu.oz.au (Fergus Henderson) wrote:
> >>So once again, I am merely asking for a reference to some documentation
> >>that might describe _why_ OPERATORS only were made visible
> >
> >Because explicit module qualifiers on OPERATORS look very ugly.
> 
> And explicit module qualifiers on enumeration literals don't?
> 

Not if suitable names are chosen.  Most of the difficulties with Ada 
prefixes and dotted names seem to arise because people fight the 
language rather than taking advantage of it.  Names should be chosen for 
their readability in context.  I much prefer:

package Valve is
  type T is (Open, Shut);
end Valve;

allowing:   DrainValve : Valve.T := Valve.Shut;

to the more common(in my experience) form:

package BasicTypes is
  type ValveType is (Open, Shut);
end BasicTypes;

which leads to: DrainValve : BasicTypes.ValveType := BasicTypes.Shut; 
which _is_ ugly.


Peter

-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/
 
--------------------------------------------------------------------------

Re: Enumeration literal visibility and use type

[John McCabe]

Peter Amey <pna@praxis-cs.co.uk> wrote:

>Not if suitable names are chosen.  Most of the difficulties with Ada 
>prefixes and dotted names seem to arise because people fight the 
>language rather than taking advantage of it.  Names should be chosen for 
>their readability in context.  I much prefer:
>
>package Valve is
>  type T is (Open, Shut);
>end Valve;
>
>allowing:   DrainValve : Valve.T := Valve.Shut;
>

That's not a bad point, but if I say:

   ValveState : Valve.T := Valve.Shut;

then do some processing then I want to check the state of the valve I 
have to do:

   if (ValveState = Valve.Shut) then ...

when I would rather just say:

   if (ValveState = Shut) then ...

I see the second one as being clearer.

Since "Valve" is alonger word than "Shut" and is the first to be read, 
there is a risk of it reducing the "obviousness" of what is intended, and 
reducing readability of the code.

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================

Re: Enumeration literal visibility and use type

[William Bralick]

In article <6kf0r3$isj$1@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@cs.mu.oz.au> wrote:
|bralick@seas.smu.edu (William Bralick) writes:
|
|>John McCabe  <jgm@hayling.cwmbran.gecm.com| wrote:
|>|... 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.
|
|What's wrong with (3) just using explicit module qualifiers?

The scenario is that the package with the enumeration type declared 
in it includes other types (but no operations), (2) this package is 
not in my control (so I cannot create a subpackage), (3) the names 
are quite descriptive (e.g. doodah.thingy_bobber.whatchamacallit), 
(4) the standard abbreviations are also not in my control, are cryptic
and require the renames we find obnoxious, viz.

   package d_tb_what renames doodah.thingy_bobber.whatchamacallit;

   -- note that it is a manual inspection task to ensure that the 
   -- standard abbreviations are used
   
   whatever : d_tb_what.cool_enumeration_type; 

   -- or, worse

   whatmore : doodah.thingy_bobber.whatchamacallit.cool_enumeration_type;
   ...

   begin

     whatever := d_tb_what.state0;

     -- or, again worse

     whatmore := doodah.thingy_bobber.whatchamacallit.state0;

   end test;

|>So once again, I am merely asking for a reference to some documentation
|>that might describe _why_ OPERATORS only were made visible
|
|Because explicit module qualifiers on OPERATORS look very ugly.

I think that a similar argument applies to enumerals.  I admit, though,
de gustibus non disputandum est.

Best regards,

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