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