From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a718bcdc37ac6307 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-25 19:13:52 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!xlink.net!fauern!news.th-darmstadt.de!terra.wiwi.uni-frankfurt.de!zeus.rbi.informatik.uni-frankfurt.de!news.dfn.de!Germany.EU.net!EU.net!howland.reston.ans.net!noc.near.net!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: derived types, constants and literals Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: Date: Mon, 24 Oct 1994 21:05:46 GMT Date: 1994-10-24T21:05:46+00:00 List-Id: In article , Scott Leschke wrote: >Has standard type derivation been modified at all in 9X. About the only change related to "untagged" derived types is that a derived type declaration can have a new discriminant_part, so long as the new discriminants are all used to constrain the discriminants of the parent subtype. This allows a private type with discriminants to be implemented using a derived type. >In particular, I was wondering if constants of a type were >derived just like the operations on that type. From messing >briefly with GNAT I gather that they can't and I was kind of >wondering if this was ever considered. Not really. Having non-overloadable declarations inherited upon type derivation would create a nasty mess. However, you can accomplish roughly the same thing by declaring parameterless functions to represent your constant values, and they will be inherited like all other primitive subprograms. You can use pragma Inline if necessary to minimize any associated overhead. > ... >It always struck me as odd that in Ada83, constants of a type could >not be derived and overridden just like operations were. Since they >aren't, one of two possibilities exists for procedure Test2.DoIt. > >Either it is derived as: > > procedure DoIt(Val : Y := Y(Test1.Null_Val)); This is essentially what happens. See RM83-3.4(13) and RM9X-3.4(22);5.0. >or an implicit local constant Null_Val is generated of the form: > > Null_Val : constant Y := Y(Test1.Null_Val); > ... No, this definitely doesn't happen. A default expression can be arbitrarily complicated. It would not be possible to make implicit local declarations for each "interesting" default expression. > ... >This is just a curiosity on my part but I thought others may be interested >in this so I posted it. If I was dreadfully wrong in this assumption, >feel free to let me know. As mentioned above, inheriting non-overloadable declarations could create numerous surprises for the user. It is a useful feature of Ada that the only implicit declarations are for overloadable things, and don't cause hiding when made visible via "use" clauses, etc. >Scott Leschke >Motorola Cellular Infrastucture Inc. S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138