Re: Renaming Fixed Point Mutiplicative operator in Ada 95

[dewar@merv.cs.nyu.edu (Robert Dewar)]

<<<<We disagree here - as we have in the past.  Fair enough.  Then how about
  enumerating the specific circumstances under which a fixed point multiply
  can raise an exception?

  My assumption was that, because the multiplication returns universal fixed,
  no exception would be raised.  So what would be the point of overriding the
  predefined operator in order to handle the "exception"?>>

>>


It is often useful to override the predefined operators in specialized
circumstances. It is of course the case that a statement like

	a := b * c;

where a,b,c are the same fixed-point type can raise constraint error.
Tecnically the exception comes from the subtype conversion of course.

But you may want, for example,to raise other than CE for a particular
case of fixed-point overflow, or you may want to write operators that
stick at the limits when out of range (such an approach might for
example have saved quite a few ECU since there would be one more
satellite in orbit, and one less embarassing Ariane explosion).

If your advice comes from an attitude of never ever overriding
predefined operators, it is at least consistent, but it is almost
always an indication of lack of perception to declare a feature
in Ada to be in the category of "this should never be used".

The major problem here is that there are indeed many reasons to want
to define your own fixed-point operators. In the case of Ada 83, this
was often done for convenience, precisely to allow

	a := b * c;

which otherwise of course is illegal in Ada 83. 

The incompatible change in Ada 95 is really an annoying incompatibility for
a lot of legacy code. Yes, sometimes it works to simply remove the 
declaration if it is just for the purposes of avoiding the conversions,
but any kind of change like that to big legacy programs is worrisome.

But if the overriding is for some other purpose (here is another application:
make a specialized "*" to count the number of multiplications performed for
performance analysis purposes), then the restriction in this case is
annoying.

Matthew seems to think that somehow this inability to redefine "*" is
a natural consequence of the wonderful power of fixed-point. But that
is clearly nonsense, since we are talking about a minor syntactic
convenience here. The problem does not exist at all in Ada 83, but
one does have to write conversions.

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.

Indeed, I think what we would have discussed would have been the two
following possibilities:

  1. Omit the feature, which adds nothing to expressive power

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

I could have been persuaded to choose option 2, but I would NEVER have
agreed to introducing this incompatibility if I had known about it!

Not only is this an annoying incomtpibility, but it is a huge gotcha!

It means for example that the otherwise perfectly reasonable approach:

define a type x which may be float on some targets fixed on others
define appropriate operators on those types

is trickier than it should be.

Matthew, I am not sure you have much experience with fixed-point, perhaps
it is limited to the cases where it is used to represent specific real world
quantities (in which case of course the profile foo X foo => foo makes no
sense).

But consider using fixed-point for poor mans floating point on a machine
with no hardware floating-point (this was always one of the anticipated
uses).

Now you would like to be able to write

	a := b * c + e * f;

but of course that is illegal. In Ada 83, you could simply defined your
own "*" and "/" and then write expressions of this kind, but there is
simply no replacement for this in Ada 95 that would also preserve literals.

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.