CVS difference for ais/ai-00364.txt

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

--- ais/ai-00364.txt	2005/01/07 03:07:44	1.13
+++ ais/ai-00364.txt	2005/01/28 02:10:49	1.14
@@ -470,3 +470,135 @@
 
 ****************************************************************
 
+From: Duncan Sands
+Sent: Thursday, January 6, 2005  10:54 AM
+
+!topic It would be better if fixed point multiplying operators were imported
+!reference RM95-4.5.5(18)
+!from Duncan Sands 05-01-06
+!keywords multiplication division universal_fixed import convention intrinsic
+!discussion
+
+When setting up a system of physical dimensions, where multiplication only
+makes sense between certain types (eg: speed * time = distance), it is
+extremely annoying that arbitrary fixed point types can be multiplied: these
+multiplications may not make physical sense, and need to be removed somehow,
+for example by defining each one to be abstract (which doesn't actually work,
+but let's ignore that).  However, this is impractical, since the number of
+operations to eliminate increases rapidly with the number of fixed point types.
+I think RM95-4.5.5(18) was a mistake and should be dropped.  Here is an
+alternative: if someone wants multiplication between fixed point types A and B
+returning type C, then they declare
+
+        function "*" (Left : A; Right : B) return C;
+
+and either write their own body, or use
+
+        pragma Import (Intrinsic, "*");
+
+to get the version RM95-4.5.5(18) would have given them.  Of course this is not
+backwards compatible, but then again neither was RM95-4.5.5(18).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 6, 2005  1:00 PM
+
+There is an Ada 2005 amendment AI which addresses this problem.
+See AI 364 on the "Ada-Auth" site:
+
+http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00364.TXT?rev=1.12
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 6, 2005  1:07 PM
+
+> ... need to be removed somehow, for example by defining each
+> one to be abstract (which doesn't actually work, but let's ignore that).
+
+Actually, it does work in Ada 2005: see AI-310 and 6.4(8/2).
+
+> ...or use
+>         pragma Import (Intrinsic, "*");
+>
+> to get the version RM95-4.5.5(18) would have given them.  Of
+> course this is not backwards compatible, but then again neither
+> was RM95-4.5.5(18).
+
+This is too incompatible, because it would eliminate operations allowed in
+Ada 83 as well as Ada 95. But no matter, Ada 2005 solves the problem by
+adding additional resolution rules (see AI-364 and 4.5.5(20/2)).
+
+****************************************************************
+
+From: Duncan Sands
+Sent: Friday, January 7, 2005  2:53 PM
+
+> Actually, it does work in Ada 2005: see AI-310 and 6.4(8/2).
+
+I am familiar with the AI, which is why I said to ignore this problem.  The AI
+does not help with the problem that it is impractical to eliminate the vast
+numbers of multiplications introduced with each new fixed point type.  The fact
+that two types declared in different packages with no relationship between them
+(except that they are both fixed point types) automagically get these
+operations is also IMHO not in keeping with the Ada philosophy of a strict type
+system and requiring operations to defined explicitly.
+
+> This is too incompatible, because it would eliminate operations allowed in
+> Ada 83 as well as Ada 95. But no matter, Ada 2005 solves the problem by
+> adding additional resolution rules (see AI-364 and 4.5.5(20/2)).
+
+I thought you would say that :)  On the other hand it is easy to fix code: just
+chuck in a declaration and a pragma Import everywhere you need one.
+
+> Next question? :-)
+
+Don't you feel that the AI solution is a hack?  Go on, confess! :)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 7, 2005  3:53 PM
+
+> I thought you would say that :)  On the other hand it is easy to fix code:
+> just chuck in a declaration and a pragma Import everywhere you need one.
+
+Ada 2005 is supposed to be a small update (if 250 pages can be called
+small!). We tried to limit incompatibilies to rarely encountered cases, so
+that vendors can introduce the new features incrementally. Breaking all code
+using fixed point hardly seems a good idea. Moreover, the Ada community is
+hardly large enough that it can be fractured into a number of incompatible
+groups and still survive.
+
+> > Next question? :-)
+>
+> Don't you feel that the AI solution is a hack?  Go on, confess! :)
+
+Not really, it is just putting things back to the Ada 83 rules without
+breaking too much. And for the many users who aren't trying to redefine
+operators and don't care which operations are used, things will still work.
+Remember, the Ada 95 rules came about because people complained about having
+to write a type conversion in:
+    A := B * 5.0;
+which was felt to make Ada look bad. Reverting to the Ada 83 rules alone
+certainly wouldn't help the situation any - and you certainly can't have it
+both ways. (Note that with your proposal, the above would always be illegal
+unless you defined an appropriate fixed*fixed multiply operator. The need to
+do that for every type declaration hardly would make Ada look good - it
+would be another instance of "nanny Ada"...)
+
+The reason for the predefined fixed*fixed operator is that you can't write
+it yourself (unlike other numeric types). And the original Ada 83 rules
+prevented accidental use (you can hardly put in a type conversion by
+accident).
+
+Alternatively, you can look at it that virtually everything that we did in
+Ada 2005 was a hack, because we had to fit things into an existing
+structure. (With the exception of a couple of cases where we got rid of
+previous hacks and replaced them with different ones. :-) But this one is
+hardly unusual (look at the rule for untagged abstract types in AI-310, for
+instance).
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent