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, MSGID_FROM_MTA_HEADER autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 126597,8019875eef785069,start X-Google-Attributes: gid126597,public X-Google-Thread: 12da6b,8019875eef785069,start X-Google-Attributes: gid12da6b,public X-Google-ArrivalTime: 1982-10-31 23:11:46 PST Message-ID: Newsgroups: net.lang.c,net.lang.ada Path: utzoo!decvax!harpo!duke!bcw X-Path: utzoo!decvax!harpo!duke!bcw From: duke!bcw Date: Mon Nov 1 02:11:40 1982 Subject: Re: Problems in C and Ada X-Google-Info: Converted from the original B-News header Posted: Sun Oct 31 20:07:09 1982 Received: Mon Nov 1 02:11:40 1982 Date: 1982-11-01T02:11:40+00:00 List-Id: From: Bruce C. Wrigt @ Duke University Re: Problems in C and Ada The overloading capabilities of Ada are definitely not the *worst* feature of the language; in fact there are very few languages which do *not* have some amount of overloading (usually small). Forth, Bliss, and BCPL are the only languages which come to my mind immediately which have *no* overloading - most languages implicitly overload operators like + so that they work with both integer and floating point arithmetic. Ada and a couple of other languages allow the user to define additional overloaded operations. I don't agree with the way it's done (I don't think it should be legal for the programmer to hide the system-defined instance of the "+" operator for integers, for example; probably at least the operators should be defined in some kind of encapsulation where the data type itself is defined and modification of the operators outside of the encapsulation should probably be illegal), but it does not strike me as an unreasonable idea. A much worse problem with Ada (unless the revised report has fixed the problem) is with the definition of fixed-point data. This is an attempt to allow a "poor man's floating point" by defining a number with a radix point (similar to PL/I's fixed point data). The problem is that the old version of the language did not define the radix in which the fixed-point data was to be stored; it just allowed the programmer to specify a delta value which is guaranteed to be greater than or equal to the smallest possible difference between two numbers. For example, if you specify a delta value of 0.1, the compiler could comply both if it compiled your data type as a fixed decimal number with one digit to the right of the decimal point, or a fixed binary number with four bits to the right of the decimal point (hence the "actual" delta would be 0.0625). This will cause obscure problems with portability and verification of code which uses the feature, since there will be unpredictable rounding effects depending on the implementation. There were several other problems with the initial report, which I think have been fixed in the final report, so this may have been fixed as well; there are several other things which they did which look much more questionable than overloading. Bruce C. Wright @ Duke University PS -- I have noted that many people on the net misspell the name of the PL/I language. The name is not PL/1, PL-1 or whatever; the ANSI committee specifically states that the correct spelling is PL/I. -- BCW