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 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!ucbvax!ANTARES.MCS.ANL.GOV!dritz From: dritz@ANTARES.MCS.ANL.GOV Newsgroups: comp.lang.ada Subject: Component names in variant parts Message-ID: <8912151850.AA25552@papasun.mcs.anl.gov> Date: 15 Dec 89 18:50:52 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: [This message was written before Dave Emery posted something similar, but it took me an extra day and some help from Karl Nyberg to figure out how to post to info-ada. Dave's message and this one are complementary and overlap only a bit.] In one recent communication, a correspondent unwittingly displayed an Ada language error by giving the same name to a record component in two different variants of the variant part of a record type definition; other correspondents pointed out the error. In another communication, the first correspondent lamented not having submitted an Ada 9X request asking for the ability to give mutually exclusive variants the same component name. There are sound reasons why the language is the way it is in the above regard, and why it is unlikely to be changed. With the rules as they are, a reference to a component in a variant part always implies an associated type that is known at compile time. The compiled code has only one type to contend with; it need only check that the reference is allowed (based on the values of one or more discriminants). The alternative that has been suggested has the consequence that the type of a referenced component might not be known at compile time. This requires the code compiled for the reference to (sometimes) contain an implicit case on the discriminant value(s). While the inefficiency of an interpretive reference is bad enough, it might be accepted in return for the additional functionality. However, there are other implications as well: it would mean that static type checking--such an integral part of Ada--would be impossible in certain contexts. That is NOT worth the added functionality of dynamically interpreted types for variants of records. The original motivation for the example leading to this discussion--conditional compilation--of course does not need *dynamically* interpreted types. In that case, the desired static parameterization of the type of a record component can (in all likelihood) be achieved by generic instantiation; variant parts are not needed. --Ken Dritz --Argonne National Laboratory --dritz@mcs.anl.gov