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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d69f4a8070dd707 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-10 23:31:13 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3EE6CCA2.9010109@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: AIs for Ada extensions References: <3EDC8FA6.2000308@noplace.com> <3EDFAC9F.5040802@cogeco.ca> <3EE5C45B.700@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc04 1055313067 24.62.164.137 (Wed, 11 Jun 2003 06:31:07 GMT) NNTP-Posting-Date: Wed, 11 Jun 2003 06:31:07 GMT Organization: AT&T Broadband Date: Wed, 11 Jun 2003 06:31:07 GMT Xref: archiver1.google.com comp.lang.ada:38953 Date: 2003-06-11T06:31:07+00:00 List-Id: 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