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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c459ff0adb576bc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-23 15:21:16 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Refactoring and Ada Date: 23 Feb 2002 15:21:15 -0800 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0202231521.4b41edf5@posting.google.com> References: <3C5AB0B7.9D75D49A@grammatech.com> <3C7324BF.996E182B@adaworks.com> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1014506476 8320 127.0.0.1 (23 Feb 2002 23:21:16 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Feb 2002 23:21:16 GMT Xref: archiver1.google.com comp.lang.ada:20320 Date: 2002-02-23T23:21:16+00:00 List-Id: "Randy Brukardt" wrote in message news:... OK, if you want my 2cents on the UC issue in more detail here it is. Yes, of course in general functions have to be allowed to behave erroneously in this case. Consider for example the case of a signalling NaN returned on a machine where you are forced to put FPT results into an FPT register. However, UC to me is only defined as a function for the convenience of the LRM. It is not a real function, and we would be shocked to find a compiler that actually called a function body using the standard calling sequence. Instead what we expect to see is very specialized intrinsic code that makes sure that UC is well behaved in this kind of regard. To argue detailed semantics of UC assuming it is an ordinary function is a mistake in my opinion. Indeed one wonder whether it would not have been better to avoid modeling UC as a function, and perhaps instead use an attribute Integer'Unchecked_Conversion (X); to make it quite clear that this is special. I also consider the above to be quite noisy enough (the with and instantiations are often a bit TOO much of a good thing). Hmm! nothing to stop an implementation putting this in and documenting its semantics as 100% operational (with a note that you can use this attribute and ignore the ARG :-)