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=1.2 required=5.0 tests=BAYES_00,FROM_DOMAIN_NOVOWEL, INVALID_DATE,MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!lll-crg!nike!ucbcad!ucbvax!hplabs!sdcrdcf!lwall From: lwall@sdcrdcf.UUCP (Larry Wall) Newsgroups: net.lang.ada Subject: Re: Ada reference manual inquiry Message-ID: <2931@sdcrdcf.UUCP> Date: Tue, 5-Aug-86 15:12:56 EDT Article-I.D.: sdcrdcf.2931 Posted: Tue Aug 5 15:12:56 1986 Date-Received: Thu, 7-Aug-86 06:12:36 EDT References: <2929@sdcrdcf.UUCP> Reply-To: lwall@sdcrdcf.UUCP (Larry Wall) Organization: System Development Corporation R&D, Santa Monica List-Id: In article <2929@sdcrdcf.UUCP> steve@sdcrdcf.UUCP (Steven Holtsberg) writes: > When operators are described, and the ``types'' of their operands > are given, do they really mean ``types'', or do they mean ``subtypes''? They really mean types. The guys who wrote the manual are really mean types too. > For example, on page 4-16 (section 4.5.3), when describing ``+'', > the manual says that the left operand can be of ``any numeric type'', > and the right operand must be of the ``same numeric type''. > > Do they really mean what I think- that is, in X + Y, > if X is a subtype of INTEGER, say POSITIVE, and Y is a another sybtype > of INTEGER, say NEGATIVE, then the _type_ of X is INTEGER > (although it is of subtype POSITIVE) and the _type_ of Y is > INTEGER, so X + Y is legal, and it is of type INTEGER? Yes. > Or do they mean that X and Y must be of the same subtype, so > if X is POSITIVE, then Y must be positive, and X + Y is > POSITIVE? No. > More generally, what is the _type_ of any constant or a variable? > Is it the subtype it was declared to have, or the base type? The base type. Note LRM 3.3.2-11: "A subtype declaration does not define a new type." > Note that on page 3-4, the ARM says that (line 5) the _subtype_ > of an object is determined by the object declaration. > But, it does not say whether this _subtype_ of the object > is also its _type_ of the object, or whether the _type_ > of the object is actually the base type. Subtypes can be thought of as just additional constraints on an implied type, sort of like global assertions (3.3-4). If you want further proof, see 4.6-3 and 4. There is, in fact, no way to convert anything to a subtype, even if you wanted to: "The target type of a type conversion is the *base type* of the type mark." Note also that the sets of operations are defined in terms of types, not subtypes (3.3-1 and 5). Hence, the addition operation for two subtypes with the same base type is in fact the same operation. The manual doesn't start talking about deriving operations until it starts talking about derived types. You could even go as far as to say that expressions don't have subtypes, only types. That is to say, evaluating an expression does not imply that any constraints are checked, except in the sense that the expression contains operations which force constraint checking. If you look in the Index (yes, I know that's not supposed to be authoritative, but it points to authoritative text) you'll see that CONSTRAINT_ERROR is raised by operations, not expression evaluation per se. In general, you can trust the LRM to be quite picky when it comes to obvious things like that. When they say type, they mean type, and when they say subtype, they mean subtype. The manual is quite picky because several thousand people were quite picky about the manual over a period of several years. Larry Wall Mark Biggar {allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall