Ada 9X features

Ada 9X features

[Ken Garlington]

I would disagree with Bevin Brett's assessment of Ada 9X requirements bloat in
one area: the ability to have access values that don't reference the heap. We
have a number of constant data structures where the use of access values
greatly simplifies the data description and the corresponding algorithms. In
the "good" old JOVIAL days, it was pretty simple to get the compiler/linker to
build this as a static structure in ROM. (From what I understand, this can also
be done in C.)

We can use Ada 83 access types, which are much clearer to read and understand
than the JOVIAL equivalent. However, we just can't afford the elaboration time,
nor the extra memory, needed to copy these large data structure into the heap.
So, we have to do nasty tricks with UNCHECKED_CONVERSION and SYSTEM.ADDRESS to
get the data structure the way we want.

When we, as a most decidedly non-academic group of Ada practitioners, were
asked what we would want in Ada 9X, we wrote MRs that discussed our problems in
this area, fully expecting to be told, "Oh, there's a simple way to do that in
Ada 83 - you just..." or "Well, you just don't have an Ada mindset..." However,
neither of these happened. Even more to our surprise, an implementation has
been proposed for Ada 9X which looks like it will work perfectly.

I can't say that I will use everything in Ada 9X. I can't defend everything
that's been added. But I hope that those features that were added based on
inputs from the "grunts" in the field are treated with the same importance as
those proposed by the vendors, even if they aren't quite as interesting...

Re: Ada 9X features

[Robert Dewar]

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

Re: Ada 9X features

[Bevin R. Brett]

In article <940908231244_73672.2025_DHR48-1@CompuServe.COM>, Ken Garlington <73672.2025@COMPUSERVE.COM> writes...
>I would disagree with Bevin Brett's assessment of Ada 9X requirements bloat in
>one area: the ability to have access values that don't reference the heap. We

All that was required to satisfy this was a Foo'access attribute and a
pragma accessed(Foo).

Instead we got an incredible collection of general access types, lifetime
checking rules, 'unchecked_access, etc.

The ability to detect violations of lifetimes should have been left to
the implementor to do if the market really wanted it.

I agree that the fundamental reqt had to be met (there is probably a couple
of other oversights too in my list - for example a simple access-to-subprogram
was also needed) but the satisfaction of that requirement is an excellent
example of feature bloat.,

/Bevin

ps: I am somewhat surprised at the quietness of the reaction to what I thought
was a very radical position for a DR to be taking publicly - perhaps more
people agree with me than I guessed.

Re: Ada 9X features

[Robert I. Eachus]

     There is a spectrum of opinion on the size of the revision, and I
find it not at all surprising that implementors tend toward the
conservative end.  Robert Dewar, Ben Brosgol, Dave Emery and I
discussed whether or not the decision to exclude COBOL P format
support from Text_IO.Editing should be reconsidered.  As the author of
the ADAR code to do picture string editing I knew the magnitude of the
change and therefore started out baised against.  (For technical
reasons I won't go into here, we eventually concluded that the
decision to leave it out is correct.  There is--in Ada--a less error
prone way to achieve the same result.)

     As an implementor, I would like the language to be smaller.  As a
user, there are a lot of features that got cut from 9X that I will
miss.  But there has to be a compromise.

     It is in the nature of Ada, and the software engineering goals
that come with the language, that the proper compromise point is one
that will cause implementors pain.  The tradeoff criteria has to be
that if pain for users can be eliminted by causing pain for
implementors, so be it.  However, the level of pain for implementors
has to be survivable.  A possible conclusion from GNAT would be that
it is survivable in Ada 9X...

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada 9X features

[Michael Feldman]

In article <940908231244_73672.2025_DHR48-1@compuserve.com>,
Ken Garlington  <73672.2025@COMPUSERVE.COM> wrote:

>I can't say that I will use everything in Ada 9X. I can't defend everything
>that's been added. But I hope that those features that were added based on
>inputs from the "grunts" in the field are treated with the same importance as
>those proposed by the vendors, even if they aren't quite as interesting...

This discussion of "creeping featurism" in Ada 9X points up just how 
difficult a consensus process is. Everyone says "this language is getting
too big; we don't need all this junk; leave _my_ favorite stuff in,
please."

To judge from some of the published reports from vendors, some are
implementing the realtime changes first, others the OO stuff first.
These two areas are more or less separable, advocated by different
constituencies with different needs. It is inevitable that priorities
will vary; the vendors say they are "following their customers' wishes."

To the extent that a vendor says "put in what _my_ customers need,
take out what _your_ customers need", this is a natural consequence
of the fragmentation of the market and of a consensus-reaching process.

GNAT is, so far, the only implementation getting close to doing it all.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------