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: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/26
Message-ID: <dewar.862111056@merv>#1/1
X-Deja-AN: 237647152
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <dewar.862054383@merv>
 <E99L96.LwI@world.std.com> <dewar.862097010@merv> <E99wI0.7BB@world.std.com>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-26T00:00:00+00:00
List-Id: <comp.lang.ada>


Bob Duff said

<<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).>>


Let's see what that para says:

20   An implementation may interpret aspects of representation in an
implementation-defined manner.  An implementation may place implementation-
defined restrictions on representation items.  A recommended level of support
is specified for representation items and related features in each subclause.
These recommendations are changed to requirements for implementations that
support the Systems Programming Annex (see C.2, ``Required Representation
Support'').

Nice, but it has nothing at all to do with the issue of predefined types
in the annex A packages. Except to say nothing at all about them, which
could have also been achieved by saying nothing at all. This para is
about rep clauses themselves, not on requirements for Annex A.

<<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.>>

Yes, but that is irrelevant to the discussion, which is about the
restrictions placed on bodies in annex A. At least that's what *I*
was talking about (remember the subject line, and we are off on
thinking about composition of equality).

In fact as you know another MAJOR unresolved issue is the status of
the annex A packages with respect to distribution. IT seems like that
is another big hole!

We also have the worrying non-portabiility of System being Pure or
Preelaborated, which is another similar issue

Are annex A packages allowed to have storage leaks? Where does it
say otherwise -- I can think of many other questions like this.