CVS difference for ais/ai-00364.txt

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

--- ais/ai-00364.txt	2004/06/08 02:50:59	1.7
+++ ais/ai-00364.txt	2004/06/10 05:39:57	1.8
@@ -1,4 +1,4 @@
-!standard  04.05.05(20)                                04-06-07  AI95-00364/02
+!standard  04.05.05(20)                                04-06-08  AI95-00364/03
 !class amendment 03-12-04
 !status work item 04-02-29
 !status received 03-09-29
@@ -23,10 +23,10 @@
-Forbid use of universal-fixed multiply operator if both operands have
+Forbid use of universal-fixed multiply operator if either operand has
 at least one primitive user-defined multiply operator.
 Similarly, forbid use of universal-fixed divide operator if
-both operands have at least one primitive user-defined divide
+either operand has at least one primitive user-defined divide
 operator. These would be Name Resolution rules.
@@ -347,3 +347,104 @@
 of this was to improve compatibility with Ada 83.
+From: Tucker Taft
+Sent: Tuesday, June 8, 2004  12:07 AM
+Oops.  The !proposal section still says "both" operands.  It
+should say "either" operand.  Also, I included the appendix
+by mistake.  Usually I omit it.
+From: Robert I. Eachus
+Sent: Wednesday, June 9, 2004  12:03 PM
+There is a discussion of this issue on comp.lang.ada, and I thought I
+should append my response here.  Tucker's solution has a huge benefit
+that the current discussion hasn't mentioned:
+Martin Dowie wrote:
+ > "Duncan Sands" <> wrote in message
+ >
+ >
+ >>Fixed point types have a remarkable property:
+ >>you can multiply any two of them to get a third.
+ >>You can multiply apples and oranges and get
+ >>bananas.  This goes against type safety.
+I agree, and I objected to the original Ada95 rule that allowed the
+explict type conversion from universal fixed to be omitted.  In addition
+to the problems created when you do want to explicitly define a multiply
+operation, it creates the serious problem Duncan refers to:
+ > Suppose I have several fixed point types, for
+ > example
+ >
+ > type Price is delta 0.01 digits ...;
+ > type Volume is delta 1.0 digits ...;
+ > type Value is delta 0.01 digits ...;
+P: Price; V: Volume; Val: Value;
+P := V * Val; -- the compiler won't object!
+ > I think this is being addressed by the ARG in AI-364
+ >
+ >
+ >
+ > Still a work item though...
+What is being worked on is actually different problem, where you do want
+to declare your own multiplication or division operators, and find that
+they can't be called in infix notation.
+That having been said, the current version exactly fixes Duncan Sands
+problem.  According to the new draft, if you declare a multiplication
+operation for Apples, all of the "special" Apple * fixed and fixed *
+Apple operations returning universal_fixed will be hidden where the user
+defined operators are visible.
+So to go back to Duncan's original complaint add:
+function "*"(Left: Price; Right: Volume) return Value;
+This will hide ALL the predefined operations that Duncan wants to get
+rid of, and any new ones that involve Price, Volume, or Value, so the line:
+P := V * Val; -- The compiler will complain that no visible "*" matches.
+Glad to be of service. ;-)
+From: Tucker Taft
+Sent: Wednesday, June 9, 2004  5:40 PM
+Good point.  The fix does eliminate the overly loose conversion
+rules associated with fixed-fixed multiply/divide in the presence of
+user-defined operators.
+One thing to note, however, is that it is not a question
+of the visibility of the user-defined operators.  It is a question
+of the *existence* of the user-defined *primitive* operators.
+If the any such operators exist in the visible part of the package, then
+the corresponding universal fixed-fixed operator is no longer
+usable with that type anywhere, even if the user-defined operator
+is *not* visible.  This is important to avoid beaujolais effects.
+(If you wish, feel free to include this clarification in a comp.lang.ada
+One other thing to mention is that the non-fixed multiply/divide
+operators are not really any better, in terms of type checking.
+They allow meters * meters = meters, and disallow
+meters * meters = square meters.  So I'm not convinced that
+the looseness of the fixed-fixed multiply/divide is worse than
+the perversity of the non-fixed operators.  But I *am* convinced
+that the inability to override the fixed-fixed operators is
+bad news, and this AI is a good thing from that perspective.

Questions? Ask the ACAA Technical Agent