Question about enumeration types

Question about enumeration types

[Reinert Korsnes]

Hi,

(sorry for somehow repeating a question)

Given the program as below.  Here I did put "E : E1" inside
a record since "E" is also a possible value for the enumeration type E1.

This is somehow verbose.  Is it a more elegant way ?

I find it boring that extending the range of possible values of
an enumeration type may easily cause conflicts with variable names,
and new variable names may cause conflicts values for enumeration
types.  I sometimes would like to have the reserved word "Exit"
as a possible value of an enumeration type....  Am I thinking
somewhat wrong ?

reinert

with Text_IO;
use  Text_IO;
procedure Atest1 is
   type E1 is (A, B, C, D, E);
   package E1_Io is new Text_IO.Enumeration_Io (E1);
   use E1_Io;

-- this conflicts with "E" as a possible value for type "E1" -- E : E1;

   type ARec_t is
     record
       E : E1;
     end record;
   ARec : ARec_t;

   begin
    ARec.E := A;

    Put(E1'First);Put(" ");Put(E1'Last);
end Atest1;

Re: Question about enumeration types

[Larry Hazel]

Reinert Korsnes wrote:
> 
> Hi,
> 
> (sorry for somehow repeating a question)
> 
> Given the program as below.  Here I did put "E : E1" inside
> a record since "E" is also a possible value for the enumeration type E1.
> 
> This is somehow verbose.  Is it a more elegant way ?

There is no conflict here.  You must always reference a record component this
way.  I think any other way would be less elegant.

> I find it boring that extending the range of possible values of
> an enumeration type may easily cause conflicts with variable names,
> and new variable names may cause conflicts values for enumeration
> types.  I sometimes would like to have the reserved word "Exit"
> as a possible value of an enumeration type....  Am I thinking
> somewhat wrong ?

At least an Ada compile will tell you about conflicts.

You can't use reserved words for anything else.  I have also wanted to use Exit
at times, but settled for Quit or Stop or some such.  Range is another reserved
word that would be the best variable name in some cases.  You just have to
qualify it in some way - Maximum_Range for instance.

Larry

Re: Question about enumeration types

[Marc A. Criley]

Reinert Korsnes wrote:
> 
> Hi,
> 
> (sorry for somehow repeating a question)
> 
> Given the program as below.  Here I did put "E : E1" inside
> a record since "E" is also a possible value for the enumeration type E1.
> 
> This is somehow verbose.  Is it a more elegant way ?
> 
> I find it boring that extending the range of possible values of
> an enumeration type may easily cause conflicts with variable names,
> and new variable names may cause conflicts values for enumeration
> types.  I sometimes would like to have the reserved word "Exit"
> as a possible value of an enumeration type....  Am I thinking
> somewhat wrong ?

Well, if you add a variable name, a type name, a procedure name, etc.,
you also have to worry about about causing conflicts with existing
variable, type, procedure, etc., names that have the same visibility, so
there's nothing particularly different about adding enumeration
literals.

One technique I've seen used is to prefix each enumeration literal with
its type name or some other convention.  For your example:

   type E1 is (E1_A, E1_B, E1_C, E1_D, E1_E);

Now you can add E1_Exit with no problem.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Question about enumeration types

[Robert Dewar]

Reinert Korsnes <Reinert.Korsnes@ffi.no> wrote in message news:<3B5D5EA5.F20EC9D7@ffi.no>...

> I find it boring that extending the range of possible values of
> an enumeration type may easily cause conflicts with variable names,

Let me assume you mean tedious here instead of boring.

Well yes, it is part of the Ada design to favor the reader over the
writer of code. Under certain circumstances, the compiler could use
type information to disambiguate:

   type r is (a,b,c);
   c : integer;

Now if we see:

   x(c);

then by looking at x we *may* be able to tell which was intended. But
the attempt is illegal.

Why?

Because it's confusing to reader of the code to have names reused in
this manner. Furthermore, obviously it does not generally work, since

   type r is (a,b,c);
   c : r;

obviously cannot work, so you have to suffer some of the tediousness
anyway. 

It's really FAR better not to casually reuse names. Sure, if you are
in an intelligent editor environment, e.g. GLIDE on GNAT, you can
click and find out what's what, but you are not always in such an
environment, and it's still a distraction.

The writer of the code has the job of finding good unambiguous, unique
names for all entities. You may find it tedious/boring to do this task
properly, but the maintainence programmers down the road will thank
you for your extra effort, and the Ada language design will to the
extent possible force you to do your job properly :-)

Now you may ask why allow overloading at all? That's a reasonable
question, the answer is that overloading can help readability *IF*
the subprograms with the same name have the same abstract purpose.

So if we see

   Put (r);

we expect that it does the same logical thing as all other versions
of Put, e.g. output an ASCII representation of r on the standard
output file (more accurately the current output file).

Now if you have a program where you have two functions

  procedure Arguement (F : Func);
  --  Supply saved argument for function F

  procedure Argument (W : Employee);
  --  Record that employee W got into an argument with management

That's bad programming, because the two procedures have nothing to
do with one another at an abstract level, and now the prograqm is
harder to read, because the reader will not know which version of
Argument is the appropriate one. Unfortunately the compiler has no
way of treating this horrible misuse of overloading as an error,
so you don't get any diagnostic in this case.

One may also raise the question of whether it is a good thing at a
more global level to have the same name mean different things in
different parts of the program, and where possible, this should be
avoided. In GNAT, there is a warning flag -gnatwh that flags all
cases of declarations hiding other declarations of the same name.

Re: Question about enumeration types

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0107260852.2dcba52a@posting.google.com...
: Now if you have a program where you have two functions
:
:   procedure Arguement (F : Func);
:   --  Supply saved argument for function F
:
:   procedure Argument (W : Employee);
:   --  Record that employee W got into an argument with management
:
: That's bad programming, because the two procedures have nothing to
: do with one another at an abstract level, and now the prograqm is
: harder to read, because the reader will not know which version of
: Argument is the appropriate one. Unfortunately the compiler has no
: way of treating this horrible misuse of overloading as an error,
: so you don't get any diagnostic in this case.

What overloading? I don't see anything overloaded here! :)

Re: Question about enumeration types

[Peter Hermann]

Robert Dewar <dewar@gnat.com> wrote:
> Reinert Korsnes <Reinert.Korsnes@ffi.no> wrote in message news:<3B5D5EA5.F20EC9D7@ffi.no>...

>> I find it boring that extending the range of possible values of
>> an enumeration type may easily cause conflicts with variable names,

> Let me assume you mean tedious here instead of boring.

> Well yes, it is part of the Ada design to favor the reader over the
                                                      ^^^^^^^^^^^
> writer of code. Under certain circumstances, the compiler could use
> type information to disambiguate:

>    type r is (a,b,c);
>    c : integer;
[snipp]

I have to thank Robert Dewar for spending his time for giving
a useful elaborated lecture on this subject, which BTW is the answer
for my casecrash problem some days ago. Convincing.
My thanks to Tucker Taft, too.

comp.lang.ada seems to be a precious source, indeed. (sometimes...)

-- 
Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
http://www.csv.ica.uni-stuttgart.de/homes/ph/
Team Ada: "C'mon people let the world begin" (Paul McCartney)