Re: DECAda/VMS - calling GETJPI

[mfb@mbunix.mitre.org (Michael F Brenner)]

 Mike Brenner said:

 "you could just assign it:

   integer_minus_1: integer := -1;
   x: unsigned_longword := unsigned_longword (integer_minus_1);

 because Ada 95 modular types truncate numbers to their modular range
 without giving a constraint_error."

 ------------
 Robert Dewar replied:

> That's quite wrong, the type conversoin checks that the value is in
> range, and the value is outside the range. Indeed if you add a constant
> to the declaration of integer_minus_1, the out of range condition will
> be detected at compile time by GNAT:
>      2.   type ul is mod 2 ** 64;
>      3.   integer_minus_1: constant integer := -1;
>      4.   x: ul := ul (integer_minus_1);
>                        |
>         >>> warning: static value out of range of type "ul" defined at line 2
>         >>> warning: "constraint_error" will be raised at runtime
>
> Yes, you can apply the unary minus operator to an unsigned vaue and get
> modular results as expected, but here the minus is applied to a signed
> type and generates a real minus one, which is definitely outside the
> range of any unsigned type.

 ------------
 Mike Brenner responded:

> That's quite right, GNAT gives the error message below, but in doing
> so it violates the Ada 95 Reference Manual and Rationale. Specifically, 
> (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations
> apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) 
> Conversion from modular to signed integer types works in a useful manner 
> so that overflow does not occur. (3.3.2 sixth paragraph) We can think 
> of this conversion as being somewhat akin to the sliding of array
> conversions. (2.12) ... the removal of the notorious irritation that
> for I in -1..100 loop was not allowed in Ada 83. It is allowed in Ada 9X.
> (3.8) We have generalized implicit subtype conversions on arrays (sliding)
> to apply in more circumstances. These new rules should minimize the times
> when an unexpected constraint_error arises when the length of the array
> value is appropriate, but the upper and lower bounds do not match the 
> applicable index constraint. ... the bounds may be freely readjusted to fit
> the context. (3.3.2 paragraph 2) The modular types are unsigned integer
> types which exhibit cyclic arithmetic. They thus correspond to the 
> unsigned types of some other languages such as C. (RM 3.5.4(1)) A modular
> type is an integer type with all arithmetic modulo a specified positive
> modulus. Such a type corresponds to an unsigned type with wrap-around
> semantics. (RM 3.5.4(19)) For a modular type, if the result of
> the execution of a predefined operator (see 4.5) is outside the base
> range of the type, the result is reduced modulo the modulus of the type
> to a value that is within the base range of the type. For a signed integer
> type, the exception constraint_error is raised by the execution of an 
> operation that cannot deliver the correct result because it is outside
> the base range of the type. For any integer type constraint_error is 
> raised by the operators /, REM, and MOD if the right operand is zero.
> (RM 4.6(30)) Numeric Type Conversion: If the target and the operand types
> are both integer types, then the result is the value of the target type
> that corresponds to the same mathematical integer as the operand. 

 ------------
 Robert Dewar responded:
 It's probably time again to repost the plea that if you suggest a solution
 to a problem, compile an example and make sure it works. No one is realiable
 enough to be 100% accurate without such a backup check, and posting incorrect
 information on Ada can cause a lot of confusion!

 ------------
 Mike Brenner responded:

> I compiled my example before posting this, and reported it as a bug
> in gnat, with an example. The fact that it fails in gnat does not mean
> the solution is erroneous; the other possibility is that the gnat
> interpretation of the Reference Manual and Rationale violates the
> above sentences. Gnat's erroneous interpretation places us at risk of 
> creating another notorious irritation, another unexpected constraint_error,
> a needless inefficiency, and a contradiction to the meaning of the words:
> Modular, Cycle, Sliding, Reduced, Wrap-Around Semantics, Useful, and 
> Cannot Occur.
 
> Recommendation: To avoid causing a lot of confusion, please change gnat
> to comply with the above sentences from the Reference Manual and Rationale,
> permitting modular, cyclical, reduced, wrap_around semantics to occur when
> converting a signed integer to an unsigned integer, providing a Useful
> operation where constraint_error does not occur.
 
 ------------
 Robert Dewar responded: 
 
 That's right GNAT violates the Rationale here. That's because the
 Rationale is wrong. TO be fair, the problem is that it reflects the
 language design as it was prior to the meeting in England.
 
 Mike, always read the RM, not the Rationale, when they disagree, the
 Ratoinale has no official status whatsoever. You cannot violate the
 Rationale really, since it is not an official document. You can
 disagree with it, and most certainly should, when the Rationale is
 incorrect.
 
 The RM is quite clear on this point (I notice you did not try to quote
 the RM to back up your incorrect interpretation, though it is certainly
 understandable that you would assume that what you read in the Rationale
 was correct).
 
 The conversion raises constraint error because the value in question is
 outside the range of the target type. Nowhere in the RM can you find a
 suggestion that modular types are treated specially in such
 conversions because there is no such special treatment.

 There are not many technical errors in the Rationale of this type. All the
 ones I know about are in this category, they reflect a change to the language
 made late on, where the Rationale did not track the change.
 
 It would be quite useful to have a comprehensive errata list for the 
 Rationale, but I do not know of one.
 
 Anyway, bottom line, GNAT is right, Mike is wrong!
 
 P.S. for the RM archeologists, the most obvious reference is in section 4.6
 28   For the evaluation of a type_conversion that is a value conversion, the
 operand is evaluated, and then the value of the operand is converted to a
 corresponding value of the target type, if any.  If there is no value of the
 target type that corresponds to the operand value, Constraint_Error is
 raised; this can only happen on conversion to a modular type, and only when
 the operand value is outside the base range of the modular type.  
 
 [seems clear enough to me!]

------------
Mike Brenner responds

Six of the quotes came from the Rationale, three of the quotes came from the
RM, and there is no contradiction between the six and the three. The gnat
interpretation is an inefficient interpretation because it requires extra
checks and extra consternation on the part of maintenance and development
programmers. The gnat interpretation is an incorrect interpretation because
it does not comply with the Reference Manual 3.5.4(19) requiring reduction
modulo the modulus; it does not comply with the Reference Manual 3.5.4(1)
requiring ALL arithmetic to be modulo the modulus (including type casting);
it does not comply with Reference Manual 4.6(30) requiring type conversion
to go to the same mathematical integer, which according to Reference Manual
3.5.4(1) is modulo the modulus.  

After going modulo the modulus, no number can be outside the range of a 
modular type. 

Paragraph 28 of Section 4.6 states that constraint_error on conversion
<can only happen on conversion to a modular type>. This is a typographical
error. It makes no sense, and it contradicts both the above three
paragraphs in the Reference Manual, and it contradicts the fact that
constraint_error is raised only on converting to a non-modular type. 

It should be changed to read <can only happen on conversion to a 
non-modular type>. 

For example, when converting to type integer and the value is out of range
of integer'first..integer'last, a constraint_error is generated. Since
modular types must never give a constraint_error, and since non-modular
types must always give a constraint_error when an out of range value is
provided to a type converter, this typographical error should be corrected. 

Recommendation: Fix this typographical error through the proper channels,
but in the meanwhile, change your interpretation of modular types back
to that of the Rationale, change gnat to convert modular types without
giving a constraint_error, and please give a reference to the meeting
in England which overrides the Rationale and how I can participate in 
future meetings of this sort.

Mike Brenner