* Re: Derived type declartion questions
1994-11-03 1:37 Derived type declartion questions BernhardM
@ 1994-11-03 14:47 ` Tucker Taft
0 siblings, 0 replies; 2+ messages in thread
From: Tucker Taft @ 1994-11-03 14:47 UTC (permalink / raw)
In article <399es2$6p2@newsbf01.news.aol.com>,
BernhardM <bernhardm@aol.com> 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
^ permalink raw reply [flat|nested] 2+ messages in thread