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
Lines: 50
In-reply-to: trent@unix.SRI.COM's message of 1 Dec 88 21:31:47 GMT


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