Derived type declartion questions

Derived type declartion questions

[BernhardM]

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 ?

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 ?

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."

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".

What is the intended meaning of these paragraphs ?

Bruce Gayliard     rusty@tinton.ccur.com
Bernhard Mulder    bm@tinton.ccur.com

Re: Derived type declartion questions

[Tucker Taft]

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