From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7fd5a5da28dace78 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Renaming Fixed Point Mutiplicative operator in Ada 95 Date: 1998/05/21 Message-ID: #1/1 X-Deja-AN: 355226584 References: <3561F32B.2F0B@innotts.co.uk> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 895755302 1824 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-05-21T00:00:00+00:00 List-Id: <<<> >> 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.