CVS difference for ai05s/ai05-0018-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0018-1.txt

--- ai05s/ai05-0018-1.txt	2006/11/10 06:44:49	1.1
+++ ai05s/ai05-0018-1.txt	2007/04/06 04:37:11	1.2
@@ -1,4 +1,4 @@
-!standard 4.9(38/2)                                    06-11-09    AI05-0018-1/01
+!standard 4.9(38/2)                                    07-04-05    AI05-0018-1/02
 !standard 12.7(6/2)
 !class binding interpretation 06-11-09
 !status work item 06-11-09
@@ -48,15 +48,112 @@
 
 !wording
 
-TDB. [I'm unclear if wording needs to be changed, and if so, what the change would be. - RLB]
+Replace 12.7(6/2):
 
+    For a formal object of mode in, the actuals match if they are static
+    expressions with the same value, or if they statically denote the same
+    constant, or if they are both the literal null.
+
+with
+
+    For a formal object of mode in, the actuals match if they are static
+    expressions with the same value, or if they statically denote the same
+    constant, or if they are both the literal null, or if the actuals
+    match via machine-rounding as described below.
+
+    The actuals are said to match via machine-rounding if 
+       - the actuals are both real static expressions; and
+       - the expected type of the actual parameter of the
+         formal package is a descendant of a formal type; and
+       - the expected type of the actual parameter of
+         the actual instance is not a descendant of a formal type; and
+       - their values are the same after the value of the actual parameter
+         of the formal package has been rounded or truncated (according to
+         the Machine_Rounds attribute of the expected type of the
+         actual parameter of the actual instance) to the nearest machine
+         number of the expected type of the actual parameter of the actual
+         instance as described in section 4.9.
+    
+Add AARM note (where does this go? at the very end of 12.7?):
+
+The motivation for matching via machine-rounding is illustrated by the
+following example:
+
+   package Pkg  is
+    generic
+        type T is digits <>;
+        C : T;
+    package G1 is
+    end G1;
+
+    package I1 is new G1 (Float, 3.14);
+
+    generic
+        type T is digits <>;
+        with package Fp1 is new G1 (T, 3.14);
+    package G2 is
+    end G2;
+
+    package I2 is new G2 (Float, I1);
+  end Pkg;
+  
+The language designers intended that this example should be legal.
+
+In this example, I1.C has the value Float'Machine (3.14) while
+G2.Fp1.C has the value 3.14 (see RM 4.9(38/2)).
+ 
+These two values are not the same (at least for most implementations).
+
+Matching via machine-rounding allows this example to be accepted.
+
 !discussion
 
-The rule of least surprise surely applies to this example. Users would be seriously
-confused if two literals with the same value didn't match for a formal package.
+In the given example, I1.C has the value Float'Machine (3.14) while
+G2.Fp1.C has the value 3.14 (see RM 4.9(38/2)).
 
-Formal matching should be done on the universal representation of literals, not
-on the "tweaked" version of them described by 4.9.
+These two values are not the same (at least for most implementations),
+which suggests that the instantiation I2 should be rejected (see 12.7(6/2)).
+
+There is general agreement that rejecting this example would be ridiculous.
+The rule of least surprise surely applies to this example. Users would be
+seriously confused if two literals with the same value didn't match for a
+formal package.
+
+The proposed wording change allows the example to be accepted.
+
+The words "as described in section 4.9" are needed in order to avoid
+having to repeat 4.9(38/2)'s rules about the case where "the value is
+exactly half-way between two machine numbers".
+
+At the Albuquerque meeting, there was some discussion of another approach
+to solving this problem. The idea (at least as I understood it) was that 
+a universal expression that is subject to an implicit conversion in some sense
+has two values - the unconverted value and the converted value - and that
+somehow 4.9(38/2) applies to the converted value while the rest of
+4.9 applies to the unconverted value. Furthermore, when 12.7(6) refers
+to static expressions having "the same value", this is supposed to mean a
+comparison of the unconverted values. There seems to be no justification
+in the RM for any of this. More importantly, introducing a new requirement that
+implementations must keep track of two static values for one expression would
+be a major change for at least some implementations.
+
+Another (bad) approach would be to view 4.9(38/2) as strictly a dynamic
+semantics rule, which would therefore have no effect on the static value
+of any expression. The problem with this interpretation is illustrated by
+the following example:
+
+  package Pkg is
+    Finer     : constant         := Long_Float'Succ (0.0);
+    Coarser   : constant Float   := Finer;    
+    Not_Equal : constant Boolean := Finer /= Long_Float (Coarser);
+    Named_Num : constant         := 1 / Boolean'Pos (Not_Equal);
+  end Pkg;
+ 
+Assume (as is typically the case) that Long_Float'Succ (0.0) is less than
+Float'Succ (0.0). For such an implementation, there seems to be
+general agreement that Not_Equal should be True and the example should be
+accepted. If 4.9(38/2) were interpreted as only a dynamic semantics rule,
+then Not_Equal would be False and the example would be rejected.
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent