Re: Implicit conversion?

[eachus@mbunix.mitre.org (Robert Eachus)]

In article <5678@sdcrdcf.sm.unisys.com> steve@sm.unisys.com (Steven Holtsberg) writes:
>
>In the following program, some implicit type conversion apparently
>takes place.  However, looking at the Standard, I cannot see where
>this should happen.
...
>with SYSTEM; use SYSTEM;
>
>procedure example is
>  x: tiny_integer;
>begin
>  x:= MAX_INT - MAX_INT;
>end example;

>With the Verdix xompiler, this program compiles and executes normally,
>so, there is apparently a convertion of 0 to TINY_INTEGER.

     No, there is an implicit conversion of MAX_INT to tiny_integer.

 >"An implicit conversion of an operand of type universal_integer
 >to another integer type...can only be applied if the operand is
 >either a numeric literal, a named number, or an attribute; such
 >an operand is called a convertible universal operand in this section.
 >An implicit conversion of a convertible universal operand is applied
 >if and only if the innermost complete context (see 8.7) determines
 >a unique (numeric) target type for the implicit conversion, and there
 >is no legal interpretation of this context without this conversion."

 >From 8.7, the innermost complete context of SYSTEM.MAX_INT in the above
 >example is the assignment statement
 >  x := MAX_INT - MAX_INT; -- corrected per following message...

      True, and this complete context determines that the unique
 target type for the conversion is tiny_integer.  If there were a
 visible declaration: "function "-" (L,R: Integer) return
 tiny_integer" then the implicit conversions would be illegal.

 >What the Verdix compiler is apparently doing is figuring out that
 >MAX_INT - MAX_INT is zero (at compile-time)...

      True, but it is not converting the result to zero, it is using
 the "-" operator for tiny_integer and doing the conversion first.
 This is legal, and must be legal, on all implementations.  However,
 it may raise an exception during execution.  The reason Verdix
 doesn't raise CONSTRAINT_ERROR or NUMERIC_ERROR is more subtile.

      If you look at 3.5.5(1) you find that implicit conversion to an
 integer type is a basic operation of the type.  In 11.6(3) (but read
 all of 11.6) "...freedom is left to an implementation for reordering
 actions...that are...basic operations other than assignments.  This
 freedom is left, as defined below, even where the execution...may
 propagate a predefined exception."

      The note in 11.6(9) makes it perfectly clear that execptions
 need not be raised for implicit conversions from universal types.  As
 for the subtraction, 4.5(7) says: "A predefined operation that
 delivers a result of an integer type (other than universal_integer)
 can only raise the exception NUMERIC_ERROR if the mathematical result
 is not a value of the type."  Zero is a value of tiny_integer, so the
 subtraction can not raise an exception.

 >At I right, or am I wrong?

      Wrong, but the language may be wrong too.  AI-315, which has not
 yet been approved, discusses the fact that 11.6 may give too much rope
 to clever compilers.  When we figure out a rule that does not inhibit
 useful optimizations like constant folding, but allows a user to
 insure that certain out-of-range expressions always raise an
 exception, the rules may change.



					Robert I. Eachus

with STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...