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: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Renaming Fixed Point Mutiplicative operator in Ada 95 Date: 1998/05/22 Message-ID: #1/1 X-Deja-AN: 355633494 References: <3561F32B.2F0B@innotts.co.uk> Organization: The Mitre Corp., Bedford, MA. Newsgroups: comp.lang.ada Date: 1998-05-22T00:00:00+00:00 List-Id: In article 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...