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,e6545823a74c7c29 X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Fixed point design error in Ada95 Date: 1998/09/17 Message-ID: #1/1 X-Deja-AN: 392230380 References: <6t6ihg$dkn1@onews.collins.rockwell.com> <6ta5h2$e0b2@onews.collins.rockwell.com> <6tb0j5$4rg$1@nnrp1.dejanews.com> <6tejfi$7pm$1@nnrp1.dejanews.com> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1998-09-17T00:00:00+00:00 List-Id: In article <6tejfi$7pm$1@nnrp1.dejanews.com> dewarr@my-dejanews.com writes: > Well I would agree he has identified this case, but it is > a very well known one that has been much discussed. It is > one of the more serious incompatibilities, and worse than > that it is a case in which Ada 83 is far superior to Ada > 95, there simply is no good solution to this in Ada 95. Sorry, the particular case of general interest that was identified was for a type which did not have ANY fixed*fixed or fixed/fixed operators. Yes, everyone has known about the overloading problem. But a type with no predefined multiply and divide operations (other than those for Integer) seems a lot easier to create. > I am not even sure Robert Eachus' solution of indtroducing > a peculiar non-standard fixed-point type is allowable from > an implementation point of view, but I am happy to leave > that issue moot, since in any case such an approach does > not help the user. Why not? RM 3.5.6(8) seems very clear: "An implementation may place arbitrary restrictions on the use of such types; it is implementation defined whether operators that are predefined for 'any real type' are defined for a a particular nonstandard real type." I guess you could argue that the operations to be disallowed are of type _universal_fixed_, but really we are talking about disallowing the implicit conversions to _universal_fixed_ for these nonstandard types. > We are considering adding a pragma in GNAT that will cause > GNAT to implement the obvious solution which should have been > put into the language in the first place, namely a preference > rule that prefers a user defined operator to the implicit > one (that is only useful in limited circumstances). Sounds reasonable. This is as you point out, purely a language extension. Actually, I personally think the right idea is to add such a rule to 8.6(29). This might be a good case for a non-binding AI, to be made binding if and when it is widely supported. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...