Ada reference manual inquiry

Ada reference manual inquiry

[Steven Holtsberg]

Perhaps the ARM answers this question somewhere, but I haven't
been able to find it.

When operators are described, and the ``types'' of their operands
are given, do they really mean ``types'', or do they mean ``subtypes''?

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?

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?

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?

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.

If you know the answer, please also back it up with references in the ARM.

Thanks

Steven Holtsberg
-------------------------------------------------------------
sdcrdcf!steve@ucla-cs or holts@ucla-cs

Re: Ada reference manual inquiry

[Larry Wall]

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