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,509b747879171fb8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-03 06:47:33 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!EU.net!uunet!noc.near.net!inmet!spock!stt From: stt@spock.camb.inmet.com (Tucker Taft) Subject: Re: Derived type declartion questions Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <399es2$6p2@newsbf01.news.aol.com> Date: Thu, 3 Nov 1994 14:47:33 GMT Date: 1994-11-03T14:47:33+00:00 List-Id: In article <399es2$6p2@newsbf01.news.aol.com>, BernhardM wrote: >PACKAGE numeric_base_types IS > TYPE integers IS NEW integer; >end numeric_base_types; > >WITH numeric_base_types; >PACKAGE numeric_types IS > TYPE int30s IS NEW numeric_base_types.integers > RANGE 0 .. 2**30-1; >END numeric_types; > >Our interpretation of LRM 4.6(15) (first paragraph 15) is that the >upper bound of the above range constraint is illegal, since the >operators "**" and "-" for integers are not visible within the package >numeric_types. LRM 3.5.4(8) references LRM 4.6. > >Is this a correct interpretation of the 1983 LRM ? Yes. >The June 94 Ada 9X Reference Manual 3.5 has been reworded. 3.5 (5) >states "For a range of a given type, the simple_expressions of the >range (likewise, the simple_expressions of the equivalent range for a >range_attribute_reference) are expected to be of the type of the >range." > >What does "expected" mean ? Specifically, what is the action required >of a compiler if the expectation is not met ? The term "expected type" is defined in RM9X-8.6(20);5.0 (the index entry for "expected type" points here, for what that's worth). In this case, it means you can either give an expression of the expected type, or of type universal_integer (which includes integer literals, integral named numbers, and certain integral attributes like 'Length). If the "expectation" is not meant, and the expression is not of one of the other types allowed for the expected type (e.g. universal_integer), then the construct is illegal. The bottom line is that the above declaration is illegal in Ada 9X as well, since the operators "**" and "-" are not directly visible. You can remedy the situation with either a use-package or a use-type clause (i.e. "use numeric_base_types;" or "use type numeric_base_types.integers;"). >Furthermore, 3.5 (9) states "If simple_expressions are given to >specify bounds, the evaluation of the range evaluates these simple >expressions in an arbitrary order, and converts them to the type of >the range." The (implicit) conversion is necessary in case they are of type universal_integer. If the expressions are already of the expected type, then the conversion does nothing. >If we assume that the "simple_expressions of the range" mentioned in >3.5 (5) are the same as the "simple_expressions given to specify bounds", >then it seems to us that paragraphs 3.5 (5) and 3.5 (9) are contradictory. > >This is based on the further assumption "expected" means "shall" or >"must". No, "expected" is looser than "shall," since it allows for universal types (among other things -- see 8.6(21,22)). >What is the intended meaning of these paragraphs ? Throughout RM9X, the term "expected type" is used to indicate that an expression should be of the specified type, or some related type (such as an appropriate universal or classwide type). >Bruce Gayliard rusty@tinton.ccur.com >Bernhard Mulder bm@tinton.ccur.com S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138 P.S. Here is the language lawyerease, in case you want it... The paragraphs following 8.6(20) define the rules relating to expected type. 8.6(22) applies in this case: If the expected type for a construct is a specific type T, then the type of the construct shall resolve to T, or: - to T'Class; or - to a universal type that covers T; or - when T is an anonymous access type ... In the case of an integer type T, the above allows you to use an expression of type T, or of type universal_integer (typically a literal, like your "0"). Note that an expression involving operators is never of type universal_integer, only literals, named numbers, and certain attributes are of type universal_integer. In Ada 83, there were operators defined for universal_integer, but the result of such an operator was no longer implicitly convertible to another integer type. In Ada 9X, being of a universal type means being implicitly convertible, so the result of using an operator is never of type universal_integer. In cases where the universal_integer operators were used in Ada 83, the Ada 9X preference rules (RM9X-8.6(29,30);5.0) would use the operators of the (non-universal) type root_integer. In Ada 9X, root_integer is a kind of "default" integer type, to be used when the context doesn't specify a particular expected type (e.g. in a named number declaration, or as the operand of an explicit conversion). In cases where the context does specify a particular expected type, the operators required are necessarily those of the expected type. In the above case, the operators of the expected type are not directly visible, so the construct is illegal (per 8.6(28)). A "use type" is the best remedy. Note that in Ada 9X, "implicit" conversion is part of the dynamic semantics -- that is a conversion is applied automatically to convert the operand which might not be of the expected type (due to the "looseness" of the matching allowed by "expected type"), to a result of the expected type. In Ada 83, "implicit" conversion was part of overload resolution. Unfortunately, this led to various problems in the overload resolution algorithm, and most Ada 83 compilers never quite got this part of the language exactly right. Furthermore, the rules caused "Beaujolais" effects in certain unusual circumstances (a "Beaujolais" effect occurs in a situation where adding or removing a use clause causes the program to change from one legal meaning to a different legal meaning -- these have been eliminated in Ada 9X). -TT