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,c3a7c1845ec5caf9
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/27
Message-ID: <E99wI0.7BB@world.std.com>#1/1
X-Deja-AN: 237653771
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <dewar.862054383@merv>
 <E99L96.LwI@world.std.com> <dewar.862097010@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-04-27T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.862097010@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I do not disagree that it is a good idea to pin down this particular
>lack of specification, but I strongly disagree with the general principle
>here. The idea of a package spec in Ada 83 or Ada 95 is that you are
>free to implement the body anyway you like, and of course there are things
>that are left open. FOr example, the paragraph above would require us to
>say things like:
>
>a) it is implementation defined what the value of x'size is for the following
>types (Address, Unbounded_String, ...)
>
>b) It is implementation defined whether it is possible to apply pragma Pack
>to arrays of types ....
>
>c) It is implementation defined what values of component size are permitted
>for arrays of types ...

All examples from chap 13.  Hmm.  It's always hard to pin things down in
that area.  But in fact we *do* say all of the above, and more, a bit
more concisely, in 13.1(20), which gives implementations permission to
pretty much anything the like, and then we give specific exceptions to
that permission (like packing an array of "0..3" has to do something
good, whereas packing an array of "access Integer" we don't require
much).

(Actually "implementation defined" is incorrect above, since that's
explicitly defined to mean "the implementer must document it".  But
that's a minor distinction, IMHO.)

Anyway, let's talk about the higher-level features of the language,
namely chaps 1..12, and skip chap 13 for this argument.  At least in
chaps 1..12 we have some hope of being precise.  There are certain
things that are implementation dependent, but if that's the case, we
should say so.  For example, the following are legitimate statements in
a language definition, when talking about the run-time semantics of
procedure calls:

    - The arguments are evaluated in left-to-right order,
      and then the procedure body is executed.

or:
    
    - The arguments are evaluated in an arbitrary order,
      and then the procedure body is executed.

But this:

    - The arguments are evaluated,
      and then the procedure body is executed.

is evil, because it leaves one wondering about the order.

- Bob