AIs for Ada extensions

["Robert I. Eachus" <rieachus@attbi.com>]

Marin David Condic wrote:

> 1) We would be totally wasting our time unless we could get some kind of 
> acceptance from the folks who could put a label on it that says 
> "Official" in some manner. There's some committee covering the Ada 
> standard that should be contacted. There are a handful of vendors out 
> there that have some level of interest in continuing to develop & 
> promote their Ada compilers. They should be contacted. If they say 
> "Yeah, we'll work with you on requirements, stamp as "Official" whatever 
> you produce and see to it that it gets distributed with the 
> compilers...." then you've got something worth working on. Anything else 
> is going to be a failure. Trying to get approval and acceptance on 
> something like this *after* it gets built won't happen. If it will, why 
> hasn't it already happened with one or more of the existing libraries?

The right thing to do here is to get busy and catch up on the proposed 
new packages in Ada0Y.  They can be found in the AIs at 
http://www.ada-auth.org/ais.html  I made up a list of the extension AI's 
I am aware of--Bob and Randy should let me know if I missed any.  Of 
course, in many cases whether an AI is a "normal" AI fixing something 
that is broken or a suggested extension is hard to characterize.  Also 
some of the AI's listed as "other than packages may end up as extension 
packages and vice-versa.  AI-234 for example may end up being resolved 
by having an explicit package that defines a "true" unsigned integer 
type.  (Or such a type may end up in package System, System.Address 
often is such a type.)

Some things to keep in mind if you want to read these AIs and comment.

1) Not all of these AIs will end up in Ada0Y or whatever you want to 
call it.  AI-323 is a good example of something that won't make it.

2) Read the AIs thoroughly before sending comments to the ARG.  If you 
are not sure whether to post here or to the ARG or the Ada-Comment list, 
post here.  There are several ARG members who read this list regularly. 
  If your post should go to the ARG, we will either suggest you send it, 
or forward it.

3) There will be a meeting of the ARG in just over a week.  Fifteen 
extension AIs are on the preliminary agenda.  So some of these AIs will 
change drastically in a couple of weeks.

4) If you do have constructive comments, be very specific.  The more 
detail in your comments, the more they will be listened to.  I think 
there should be a package for ZZZ is not useful.  I think this package 
(see listing below with explantion) should be made part of the standard, 
is more likely to be listened to--and result in lots of other comments.

5) If you want to submit a new package proposal, go ahead.  But have a 
package you use for a rough proposal at least.  "Wouldn't it be nice to 
have..." doesn't belong in the standard.  (If you do have a package that 
your group and several other groups uses, those are good candidates for 
inclusion.)

If you have thin skin or a big ego think carefully before sticking your 
head up.  People don't get attacked at ARG meetings or on the ARG list, 
but ideas get sliced into shreds--often by the original author.  (Think 
of submitting ideas to the ARG as akin to throwing a chunk of meat to a 
well-trained sled dog team.  The dogs may be nice to each other, but the 
meat is going to get torn to shreds and thrown around a lot.) 
Eventually, of course, all of the potential issues have been dealt with, 
and the final proposal may look nothing like the original.  At that 
point the ARG will move on to the next AI.

This is necessary.  You don't want half-baked or changes that were not 
thoroughly examined added to the language.  But it also means that many 
people are best off submitting ideas to the ARG through filters (like 
this newsgroup).  If half a dozen people agree on a particular package 
specification, it might not get torn up too badly by the ARG.  But more 
important, if you are not the only author, you won't take the criticism 
so personally.

So if you want to participate read the e-mail comments on some of these 
AIs. You may then want to arrange to be invited to an ARG meeting.  If 
you survive the meeting, you may even want to join.  Feeling mentally 
wrung out at the end of a meeting is nothing to worry about.  It means 
you were actually following the discussions.  Some of these AIs take 
more than a day to fully understand, and the ARG often deals with more 
than a dozen per day.  Of course, some AIs go through several meetings 
before they are finished.  Some issues are best dealt with in a meeting, 
others are better handled by e-mail.  So a typical resolution is for the 
ARG to accept a set of revisions "in principle," delegate revising the 
AI to someone.  This will be discussed by e-mail and then either an 
e-mail vote is taken, or it goes on the agenda for.the next meeting (again).

Proposed new packages:

AI-248 Directory Operations
AI-282 Ada unit information symbols
AI-292 Sockets Operations (Has a general discussion about standarizing
                            new packages.)
AI-296 Vector and matrix operations
AI-297 Timing Events
AI-301 Missing operations in Ada.Strings.Unbounded
AI-302 Data structure components for Ada
AI-307 Execution-Time Clocks
AI-324 Physical Units Checking

Language Extenstions for Ada0Y other than packages:

AI-217 Handling Mutually Dependent Type Definitions that Cross Packages
           (See also AI-10217, AI-20217, AI-30217, AI-40217 and AI 50217)
AI-218 Accidental overloading when overriding
            (See also AI-10218)
AI-222 Feature control
AI-224 pragma Unsuppress
AI-230 Generalized use of anonymous access types
AI-231 Access-to-constant parameters and null-excluding subtypes
AI-234 Unsigned integer types
AI-249 Ravenscar profile for high-integrity systems
AI-250 Protected Types, Extensible, Tagged, Abstract
AI-251 Abstract Interfaces to provide Multiple Inheritance
AI-252 Object.Operation Notation
AI-254 Downward closures for access to subprogram types
AI-257 Restrictions for implementation-defined entities
AI-260 How to control the tag representation in a stream
AI-261 Extending enumeration types
AI-262 Access to private units in the private part
AI-264 Exceptions as Types
AI-265 Partition Elaboration Policy for High-Integrity Systems
AI-266 Task Termination procedure (See also AI-10266)
AI-267 Fast float-to-integer conversions
AI-270 Stream item size control
AI-274 Requiring complete record representation clauses
AI-281 Representation of enumeration type image attribute
AI-284 Nonreserved keywords
AI-285 Support for 16-bit and 32-bit characters
AI-286 Assert pragma
AI-287 Limited Aggregates Allowed
AI-288 Pre/Postconditions and Invariants
AI-290 Declaring functions Pure
AI-294 Built-in hash function
AI-298 Non-Preemptive Dispatching
AI-299 Defaults for generic formal parameters
AI-300 The standard storage pool
AI-305 Data structure components for Ada
AI-310 Ignore abstract nondispatching subprograms during overloading
AI-314 Standardize Discard_Names
AI-315 Full support for IEEE 754
AI-317 Partial Parameter Lists for Formal Packages
AI-318 Object_Size attribute
AI-322 User-defined operator symbols
AI-323 Allow in out parameters for functions (Status No Action, and that
                                           is highly unlikely to change.)
AI-325 Anonymous access types as function result types (depends on
                                           AI-230)
AI-326 Tagged incomplete types
AI-327 Dynamic Ceiling Priorities