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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!cme!leake From: leake@cme.nbs.gov (Stephe Leake) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <773@marvin.cme.nbs.gov> Date: 7 Dec 88 16:21:57 GMT References: <24856@sri-unix.SRI.COM> <755@marvin.cme-durer.ARPA> <24934@sri-unix.SRI.COM> Organization: National Institute of Standards & Technology, Gaithersburg, MD In-reply-to: trent@unix.SRI.COM's message of 1 Dec 88 21:31:47 GMT List-Id: In article <24934@sri-unix.SRI.COM> trent@unix.SRI.COM (Ray Trent) writes: ... I mostly object to the internal inconsistancies of Ada...exceptions to the rules for "special" operators, the non-object status of certain types of procedural objects and not others, disallowing user definition of attributes, the wierdnesses inherent in the "use" clause that make it almost useless, the fact that Ada is supposed to be strongly typed, but that uninitialized variables of a type are not required to contain a valid value in the range of that type, and are also not required to contain an *invalid* value, etc., etc. That is the purpose of this discussion; to find the "inconsistencies" in Ada, and propose solutions. So far, I don't think any of the proposed solutions are better than what we already have. Certainly Ada is more consistent than C! Also remember that Ada is very powerful, and is _not_ simple; things that may appear inconsistent are actually logical consequences of this power. LRM 11.6 [6] states: Similarly, additional freedom is left to an implementation for the evaluation of numeric simple expressions. For the evaluation of a predefined operation, an implementation is allowed to use the operation of a type that has a range wider than that of the base type of the operands, provided that this delivers the exact result, even if some intermediate results lie outside the range of the base type. They only explicitly allow this for predefined operations, though it's ambiguous enough that vendors are likely to allow it for user-defined operations as well. (and it's kind of hard to test) I object to "special" properties of language constructs that I am not "allowed" as a programmer to use or duplicate in my own types, subprograms, etc., in any event. I don't see any ambiguity: "numeric simple expressions" and "predefined operations" are very well defined, and user ADT's do not fit the definitions! On the other hand, I agree that this is a "special" exception to the general rule. It has a very good justification, however; any hardware must have only a few types (32 and 16 integers, 64 and 32 bit float, for example) to be efficient (although I sometimes daydream about the connection machine, where I could implement a 25 bit float if I wanted to :-). Ada was intended to be a practical language, as well as an abstract one. Thus compromises are sometimes necessary. Stephe Leake (301) 975-3431 leake@cme.nbs.gov National Institute of Standards and Technology (formerly National Bureau of Standards) Rm. B-124, Bldg. 220 Gaithersburg, MD 20899