Re: Renaming Fixed Point Mutiplicative operator in Ada 95

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <dewar.895754578@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > In the Ada 95 design, it seemed quite nice to allow the conversions to
 > be omitted for an assignment like the above one, and we all agreed, but
 > at the time *no one* realized that we were introducing a nasty non-upwards
 > compatibility. I for one (and I suspect others) would have been opposed
 > to this convenience frill if we had known it would introduce an
 > incompatibility.

   I think that I remember a version of the preference rule that got
this wrong--under no circumstances do you want to prefer operators
returning _universal_fixed_--and I thought there was a corrected
version which got this right.  Sigh!

 >    2. Include the feature, but add a special preference rule to
 >	   maintain compatibility.

   I could be sold on fixing this correctly, but I would want to be
sure that the new preference rule didn't do unanticipated harm.

 > To explain this further, you can of course encapsulate your fixed-point
 > type within a record, and then of course you can define your own "*",
 > but then you lose literals.

   Depends on how brave you are.  Paragraph 3.5.6(8) allows an
implementation to provide non-standard real types for just this
purpose.  You could modify GNAT if you felt up to it, or I'm sure if
you ask your compiler vendor nicely, he will give you a quote.  Don't
be surprised if it is pretty high--the testing required could be
fierce, even if the implementation is simple.

   Non-standard integer types are also allowed, see RM 3.5.4(26), and
I keep expecting to see implementations use such a type for
System.Address.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...