* Renaming of enumeration constant @ 2004-06-10 15:37 Xenos 2004-06-10 17:38 ` Nick Roberts 2004-06-12 4:01 ` Robert I. Eachus 0 siblings, 2 replies; 8+ messages in thread From: Xenos @ 2004-06-10 15:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-10 15:37 Renaming of enumeration constant Xenos @ 2004-06-10 17:38 ` Nick Roberts 2004-06-10 20:40 ` Xenos 2004-06-11 9:25 ` Jean-Pierre Rosen 2004-06-12 4:01 ` Robert I. Eachus 1 sibling, 2 replies; 8+ messages in thread From: Nick Roberts @ 2004-06-10 17:38 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-10 17:38 ` Nick Roberts @ 2004-06-10 20:40 ` Xenos 2004-06-11 9:25 ` Jean-Pierre Rosen 1 sibling, 0 replies; 8+ messages in thread From: Xenos @ 2004-06-10 20:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-10 17:38 ` Nick Roberts 2004-06-10 20:40 ` Xenos @ 2004-06-11 9:25 ` Jean-Pierre Rosen 2004-06-11 12:00 ` Nick Roberts 2004-06-12 4:34 ` Robert I. Eachus 1 sibling, 2 replies; 8+ messages in thread From: Jean-Pierre Rosen @ 2004-06-11 9:25 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-11 9:25 ` Jean-Pierre Rosen @ 2004-06-11 12:00 ` Nick Roberts 2004-06-11 12:49 ` Dmitry A. Kazakov 2004-06-12 4:34 ` Robert I. Eachus 1 sibling, 1 reply; 8+ messages in thread From: Nick Roberts @ 2004-06-11 12:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-11 12:00 ` Nick Roberts @ 2004-06-11 12:49 ` Dmitry A. Kazakov 0 siblings, 0 replies; 8+ messages in thread From: Dmitry A. Kazakov @ 2004-06-11 12:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-11 9:25 ` Jean-Pierre Rosen 2004-06-11 12:00 ` Nick Roberts @ 2004-06-12 4:34 ` Robert I. Eachus 1 sibling, 0 replies; 8+ messages in thread From: Robert I. Eachus @ 2004-06-12 4:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Renaming of enumeration constant 2004-06-10 15:37 Renaming of enumeration constant Xenos 2004-06-10 17:38 ` Nick Roberts @ 2004-06-12 4:01 ` Robert I. Eachus 1 sibling, 0 replies; 8+ messages in thread From: Robert I. Eachus @ 2004-06-12 4:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-06-12 4:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-06-10 15:37 Renaming of enumeration constant Xenos 2004-06-10 17:38 ` Nick Roberts 2004-06-10 20:40 ` Xenos 2004-06-11 9:25 ` Jean-Pierre Rosen 2004-06-11 12:00 ` Nick Roberts 2004-06-11 12:49 ` Dmitry A. Kazakov 2004-06-12 4:34 ` Robert I. Eachus 2004-06-12 4:01 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox