Renaming of enumeration constant

Renaming of enumeration constant

[Xenos]

Just a curiosity question:

What is the difference (advantages, etc.) of defining a function rename for
an enumeration constant over just creating a constant.  Consider:

package X is
  type E is (A, B, C);
end X;

with X;
package Y is
   function A return X.E renames X.A;
end Y;

with X;
package Z is
  A : constant X.E := X.A;
end Z;

Is the "A" in Y treated any different than the "A" in Z by the compiler, or
will both achieve the same results.  Is one considered "better" (whatever
that means) than the other?

Thanks,

DrX

Re: Renaming of enumeration constant

[Nick Roberts]

"Xenos" <dont.spam.me@spamhate.com> wrote in message
news:ca9v8l$5gb8@cui1.lmms.lmco.com...

> Just a curiosity question:
>
> What is the difference (advantages, etc.) of defining a function rename
for
> an enumeration constant over just creating a constant.  Consider:
>
> package X is
>   type E is (A, B, C);
> end X;
>
> with X;
> package Y is
>    function A return X.E renames X.A;
> end Y;
>
> with X;
> package Z is
>   A : constant X.E := X.A;
> end Z;
>
> Is the "A" in Y treated any different than the "A" in Z by the compiler,
or
> will both achieve the same results.  Is one considered "better" (whatever
> that means) than the other?

I think the answer to your question is actually about inheritance.

Suppose we have the following packages:

   package Farm is
      type Leggedness is (Four_Legs, Two_Legs);
      Bipedal: constant Leggedness := Two_Legs;
      function Quadrupedal return Leggedness renames Four_Legs;
      ...
   end;

   with Farm;
   package Zoo is
      type Podality is new Farm.Leggedness;
      ...
   end;

In this situation, there will be an inherited operation:

   function Quadrupedal return Podality renames Four_Legs;

in which the Four_Legs value it returns is of the type Podality. This
operation is inherited, because it is a primitive operation of the type
Leggedness (it is declared directly in the same package specification). In
fact, this is why we get the names Four_Legs and Two_Legs for values of the
type Podality: they are functions, and they are primitive operations, so
they are inherited.

The constant Bipedal, however, is not inherited.

My own opinion is that constants are silly in Ada, but they were introduced
in Ada 83 (and its predecessors), long before the question of inheritance
was understood to be important. The advantage that constants have is that
their declaration is simpler and perhaps more obvious, and it doesn't matter
if they do not need to be inherited.

I sometimes wish to derive a type from
Ada.Strings.Unbounded.Unbounded_String, and I am annoyed that I have to
redeclare the constant Null_Unbounded_String (because it is not inherited).
It gives me the opportunity to play with names:

   type Teacher_Name is new Ada.Strings.Unbounded.Unbounded_String;

   Null_Teacher_Name: constant Teacher_Name :=
      Teacher_Name(Ada.Strings.Unbounded.Null_Unbounded_String);

but inheritance doesn't usually prevent the introduction of new names (as
renamings of functions or procedures).

For interest, compare the following possible alternative package
specifications for Zoo:

   with Farm;
   package Zoo is
      subtype Podality is Farm.Leggedness;
      ...
   end;

In this example, Podality is declared simply as a subtype of Farm.Leggedness
(without reducing the set of values). This is really just a way of renaming
a (sub)type. Since Zoo.Podality and Farm.Leggedness are of the same type, no
conversion is required between values of either subtype.

   with Farm;
   package Zoo is
      type Podality is range 0..100;
      function To_Leggedness (B: Podality) return Farm.Leggedness;
      function To_Podality (L: Farm.Leggedness) return Podality;
      ...
      Invalid_Legs: exception;
   end;

Here we declare a new type Podality altogether (which can cope with
centipedes and fish), and provide functions to convert to and from
Farm.Leggedness. The function To_Leggedness raises the exception
Invalid_Legs if B is neither 2 nor 4.

HTH

-- 
Nick Roberts

Re: Renaming of enumeration constant

[Xenos]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:2irkl9Fqi7qpU1@uni-berlin.de...

> I think the answer to your question is actually about inheritance.
>
> Suppose we have the following packages:
>
>    package Farm is
>       type Leggedness is (Four_Legs, Two_Legs);
>       Bipedal: constant Leggedness := Two_Legs;
>       function Quadrupedal return Leggedness renames Four_Legs;
>       ...
>    end;
>
>    with Farm;
>    package Zoo is
>       type Podality is new Farm.Leggedness;
>       ...
>    end;
>
> In this situation, there will be an inherited operation:
>
>    function Quadrupedal return Podality renames Four_Legs;
>
> in which the Four_Legs value it returns is of the type Podality. This
> operation is inherited, because it is a primitive operation of the type
> Leggedness (it is declared directly in the same package specification). In
> fact, this is why we get the names Four_Legs and Two_Legs for values of
the
> type Podality: they are functions, and they are primitive operations, so
> they are inherited.
>
> The constant Bipedal, however, is not inherited.
>
> My own opinion is that constants are silly in Ada, but they were
introduced
> in Ada 83 (and its predecessors), long before the question of inheritance
> was understood to be important. The advantage that constants have is that
> their declaration is simpler and perhaps more obvious, and it doesn't
matter
> if they do not need to be inherited.
>
> I sometimes wish to derive a type from
> Ada.Strings.Unbounded.Unbounded_String, and I am annoyed that I have to
> redeclare the constant Null_Unbounded_String (because it is not
inherited).
> It gives me the opportunity to play with names:
>
>    type Teacher_Name is new Ada.Strings.Unbounded.Unbounded_String;
>
>    Null_Teacher_Name: constant Teacher_Name :=
>       Teacher_Name(Ada.Strings.Unbounded.Null_Unbounded_String);
>
> but inheritance doesn't usually prevent the introduction of new names (as
> renamings of functions or procedures).
>
> For interest, compare the following possible alternative package
> specifications for Zoo:
>
>    with Farm;
>    package Zoo is
>       subtype Podality is Farm.Leggedness;
>       ...
>    end;
>
> In this example, Podality is declared simply as a subtype of
Farm.Leggedness
> (without reducing the set of values). This is really just a way of
renaming
> a (sub)type. Since Zoo.Podality and Farm.Leggedness are of the same type,
no
> conversion is required between values of either subtype.
>
>    with Farm;
>    package Zoo is
>       type Podality is range 0..100;
>       function To_Leggedness (B: Podality) return Farm.Leggedness;
>       function To_Podality (L: Farm.Leggedness) return Podality;
>       ...
>       Invalid_Legs: exception;
>    end;
>
> Here we declare a new type Podality altogether (which can cope with
> centipedes and fish), and provide functions to convert to and from
> Farm.Leggedness. The function To_Leggedness raises the exception
> Invalid_Legs if B is neither 2 nor 4.
>
> HTH
>
> -- 
> Nick Roberts
>
>

Thanks for taking the time to writing this.  I found it VERY informative.

DrX

Re: Renaming of enumeration constant

[Jean-Pierre Rosen]

> My own opinion is that constants are silly in Ada, but they were introduced
> in Ada 83 (and its predecessors), long before the question of inheritance
> was understood to be important.
Sorry, but this statement is wrong.
Before he wrote the LIS compiler (one of Ada's ancestors), Ichbiah was famous for writing the first Simula compiler in France. He
understood perfectly well inheritance. The absence of inheritance in Ada 83 was deliberate, and derived types were introduced in
Ada83 because Ichbiah insisted on it, due to his previous experience.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Renaming of enumeration constant

[Nick Roberts]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:n3ubac.l3a.ln@skymaster...

> > My own opinion is that constants are silly in Ada, but they were
> > introduced in Ada 83 (and its predecessors), long before the question
> > of inheritance was understood to be important.

> Sorry, but this statement is wrong.

> Before he wrote the LIS compiler (one of Ada's ancestors), Ichbiah was
> famous for writing the first Simula compiler in France. He understood
> perfectly well inheritance. The absence of inheritance in Ada 83 was
> deliberate, and derived types were introduced in Ada83 because Ichbiah
> insisted on it, due to his previous experience.

Exactly my point, Jean-Pierre, actually! Jean Ichbiah understood the
importance of being able to derive types -- and thank the Lord that he
did -- but very few other people connected with the development of the
Ada language did. There is documentary evidence of this. I have read, in
several places, comments on derivation in Ada 83 such as "but this
feature is not expected to be often used."

Jean Ichbiah was brilliant, and well worthy of being considered the father
of the Ada language. I think the fact that Ada 83's inheritance turned out
to be the trump card in the design of Ada 95 is testimony to his unique
foresight.

-- 
Nick Roberts

Re: Renaming of enumeration constant

[Dmitry A. Kazakov]

On Fri, 11 Jun 2004 13:00:17 +0100, "Nick Roberts"
<nick.roberts@acm.org> wrote:

>"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
>news:n3ubac.l3a.ln@skymaster...
>
>> > My own opinion is that constants are silly in Ada, but they were
>> > introduced in Ada 83 (and its predecessors), long before the question
>> > of inheritance was understood to be important.
>
>> Sorry, but this statement is wrong.
>
>> Before he wrote the LIS compiler (one of Ada's ancestors), Ichbiah was
>> famous for writing the first Simula compiler in France. He understood
>> perfectly well inheritance. The absence of inheritance in Ada 83 was
>> deliberate, and derived types were introduced in Ada83 because Ichbiah
>> insisted on it, due to his previous experience.
>
>Exactly my point, Jean-Pierre, actually! Jean Ichbiah understood the
>importance of being able to derive types -- and thank the Lord that he
>did -- but very few other people connected with the development of the
>Ada language did. There is documentary evidence of this. I have read, in
>several places, comments on derivation in Ada 83 such as "but this
>feature is not expected to be often used."
>
>Jean Ichbiah was brilliant, and well worthy of being considered the father
>of the Ada language. I think the fact that Ada 83's inheritance turned out
>to be the trump card in the design of Ada 95 is testimony to his unique
>foresight.

Amen

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Renaming of enumeration constant

[Robert I. Eachus]

Jean-Pierre Rosen wrote:

> Ada83 because Ichbiah insisted on it, due to his previous experience.

I remember a comment by Robert Dewar about a DR meeting where the issue 
of removing derived types from Ada was discssed.  Robert said: "...the 
vote was 8 to Ichbiah, so it will probably be reversed."

Robert was right on the reversal, but I always remember that comment by 
Robert Dewar when anyone says that Ada was designed by a committee. 
There were a lot of committees that had input into and influence over 
the final form of Ada 83, but Jean Ichbiah always had the last say after 
he listened to all the input.

I also remember when the first thing that Jean Ichbiah--or anyone--said 
to me at an early AdaTEC meeting in SanDiego was "Seven insults.  Seven 
insults in one paragraph what were you thinking of?"

I sort of looked blank and he said, "You were talking about the new rule 
forbidding nested accept statements."

"Only seven?  I thought there were more than that, but they had nothing 
to do with you."

"Some were in the next paragraph."

"Okay, I think the problem is that you were not at the first AdaTEC 
meeting in New York..."

There was a problem in Ada 80, that the parameter declarations for 
accept statements were elaborated when the task was created.  I showed a 
nasty example that "proved" that this needed to be fixed in the 
Reference Manual.  But some people didn't understand that my nasty 
example was just that, and tried it against the ALS and AdaEd 
implementations.

The result was what erroneous programs only threaten to do, unimaginable 
chaos.  In the case of AdaEd, it crashed not only AdaEd, but the VAX it 
was running on, due to a known bug in VMS.

So at the next DR meeting, nested accept statements must go.  Of course, 
the bug in the reference manual was fixed also, so there was no need to 
outlaw nested accept statements.  But that rule is still in the 
language.  (Of course, the 'insults' were aimed at the people who didn't 
understand the example, and ignored the "-- disaster" comment in my 
example.  I still think some of them were descriptive, not insults:  "of 
all the stupid, idiotic, bird-brained things to do,...)

Then again, I remember EE students presented with a "Handy-Dandy Fuse 
Tester" plugging it into a wall-socket and pressing the button.  (The 
label of course said "If indicator light goes out when button is 
pressed, fuse was good.")

Some things did get into Ada that Ichbiah didn't like, like the support 
for terminals that did not allow full ASCII.  But if he felt strongly 
about something, he stood his ground.

-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004

Re: Renaming of enumeration constant

[Robert I. Eachus]

Xenos wrote:

> Just a curiosity question:
> 
> What is the difference (advantages, etc.) of defining a function rename for
> an enumeration constant over just creating a constant.  Consider:
> 
> package X is
>   type E is (A, B, C);
> end X;
> 
> with X;
> package Y is
>    function A return X.E renames X.A;
> end Y;
> 
> with X;
> package Z is
>   A : constant X.E := X.A;
> end Z;
> 
> Is the "A" in Y treated any different than the "A" in Z by the compiler, or
> will both achieve the same results.  Is one considered "better" (whatever
> that means) than the other?

The difference is that a function will overload other functions and 
procedures of the same name, while a constant will hide such names in 
the local scope, and prevent them from being use visible.

So if you have two packages that declare function A, and use clauses for 
both packages you can call either, unless the call is ambiguous.  If you 
have two packages that declare constants A, and use clauses for both, 
you will still have to use a qualified name to reference A.

A different advantage to using functions instead of constants is that 
you can do the renaming in the body of the package:

package Foo is
   function A return Bar;
...
package body Foo is
   function A renames...

I'll let you read about the joys and issues of renaming as body. But if 
the value may change during development, this is the form you want.

The advantage of the constant form is when you want it to be static.

For example:

     Pi: constant := 3.14159_26...;

(If the value of Pi changes the need to modify your program is a minor 
detail.)
-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004