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
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cdf9d37fddaced23
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-09-10 13:10:00 PST
Path: 
 nntp.gmd.de!xlink.net!slsv6bt!slbh01.bln.sel.alcatel.de!rcvie!Austria.EU.net!EU.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody
From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Ada 9X features
Date: 9 Sep 1994 09:22:51 -0400
Organization: Courant Institute of Mathematical Sciences
Message-ID: <34pnjb$7cs@gnat.cs.nyu.edu>
References: <940908231244_73672.2025_DHR48-1@CompuServe.COM>
NNTP-Posting-Host: gnat.cs.nyu.edu
Date: 1994-09-09T09:22:51-04:00
List-Id: <comp.lang.ada>

In regard to Ken Garlington's post regarding access types, it is interesting
to note historically that this particular use of access-to-object was *the*
most convincing argument that this feature should be added to Ada 9X. It
is indeed the case that there was no good way of solving the problem in
Ada 83. The nervousness about the feature is that it opens the way to
undiscimplined aliasing, and any usage guide for 9X should discuss the
issues of minimizing the use of the aliased keyword.

Regarding Bevin's general view of 9X. One of the dynamics of the devlopment
of 9X has been a large scale discussion (that's American for argument) about
the scale of the change. If you look back to say mapping document 2.0, you
can see that the design team originally wanted a much more extensive change,
and on the other hand the "Swedish letter" [sorry I forget the author, it's
always referred to by that code name :-) recommended doing almost nothing to
Ada 83. Various people lay somewhere between these extremes. Jean Ichbiah
for example would have liked to see some OO stuff, character stuff fixed up
and pretty much nothing else. Bevin was certainly on the conservative end
of this debate (worrying, quite legitimately, about the difficulty of getting
implementations starting with existing Ada 83 bases).

Speaking personally, I also felt that the original proposals were far too
extensive, and indeed argued, oops excuse me, discussed, pretty fiercely
the need to cut things back. The result is a compromise which has left
most people but certainly not everyone, satisfied that we have found the
right level. The fact that it is likely that there will be unanimous
approval of the standard at the ISO level tends to confirm this judgment.
I certainly feel that from a language point of view, we are at about the
right level, although with my implementors hat on, I sure have to agree that
implementing Ada 9X is not easy [although, interestingly, in the GNAT project,
we find the most difficult parts of Ada 9X are elements of Ada 83 that are
pretty much unchanged (e.g. %$#@# private types, discriminants, aggregates
and generics).

Interesting note: the word compromise, used as a noun rather than a verb, has
pretty much positive connotations in British English, and if a meeting reaches
a compromise that people can agree on, people feel they have accomplished
what they set out to do. In American English, the noun compromise is more
closely related to the verb compromise, and tends to have negative
connotations. When I use compromise in the previous paragraph, I am definitely
using it in the positive sense.

Robert

(now back to another attack on those private types and aggregates :-)