CVS difference for ais/ai-00364.txt

Differences between 1.9 and version 1.10
Log of other versions for file ais/ai-00364.txt

--- ais/ai-00364.txt	2004/07/27 23:01:06	1.9
+++ ais/ai-00364.txt	2004/11/14 06:37:20	1.10
@@ -1,4 +1,4 @@
-!standard  04.05.05(20)                                04-06-29  AI95-00364/04
+!standard  04.05.05(20)                                04-11-07  AI95-00364/04
 !class amendment 03-12-04
 !status Amendment 200Y 04-06-29
 !status ARG Approved 7-1-1  04-06-13
@@ -10,7 +10,7 @@
 
 !summary
 
-This proposal alleviates the upward incompatibility created by Ada 95 for
+This proposal eliminates the upward incompatibility created by Ada 95 for
 users defining their own fixed-point multiply or divide operators.
 
 !problem
@@ -24,10 +24,10 @@
 
 !proposal
 
-Forbid use of universal-fixed multiply operator if either operand has
+Forbid use of the universal-fixed multiply operator if either operand type has
 at least one primitive user-defined multiply operator.
-Similarly, forbid use of universal-fixed divide operator if
-either operand has at least one primitive user-defined divide
+Similarly, forbid use of the universal-fixed divide operator if
+either operand type has at least one primitive user-defined divide
 operator. These would be Name Resolution rules.
 
 !wording
@@ -70,7 +70,7 @@
 primitive operators are *not* visible.
 
 Note that we still allow the universal-fixed operators to be considered
-if there is an explicit conversion on the result. This is provides
+if there is an explicit conversion on the result. This provides
 Ada 83 compatibility. This implies that ambiguity is still possible, but
 only in the same places where ambiguity existed in Ada 83. A qualified
 expression on the result can be used to break the ambiguity in favor of
@@ -80,7 +80,7 @@
 for which there is a visible user-defined operator.
 
 Note that the proposed rule specifies that "either" needs to have a
-user-defined primitive operator, but it could be phrased as "both."
+user-defined primitive operator, but it could be phrased as "both".
 "Both" makes sense if multiple fixed-point types are defined in the same
 scope. "Either" makes sense if fixed-point types tend to be defined each
 in their own package, because the "first" one defined would likely not

Questions? Ask the ACAA Technical Agent