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,54c513170bafd693 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Desirability of C++ Date: 2000/05/04 Message-ID: <39118BC4.4CC160DB@earthlink.net>#1/1 X-Deja-AN: 619161105 Content-Transfer-Encoding: 7bit References: <390DEC7F.9429C82C@online.no> <390E2A20.B647D0D6@maths.unine.ch> <8em8mb$evd$1@wanadoo.fr> <390EEF24.BD36AA24@maths.unine.ch> <8eonmi$e4q$2@wanadoo.fr> <39103CBE.7D5B9F4E@quadruscorp.com> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 957451173 63.24.56.153 (Thu, 04 May 2000 07:39:33 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Thu, 04 May 2000 07:39:33 PDT Newsgroups: comp.lang.ada Date: 2000-05-04T00:00:00+00:00 List-Id: "Marin D. Condic" wrote: > I can understand the reasons for arguing that the standard should not > include libraries that are not "language" issues. Obviously the > hard-core end of the spectrum which wanted few/no libraries is no longer > in vogue with Ada95 specifying many new libraries. It would seem to me > that there might be some big advantages (for the language, at least, if > not for vendors) to letting the pendulum swing further in the other > direction. Why not specify even more libraries than are presently > available so long as they are optional annexes? In this sense the language standard is evolving, and someday there will be a new Ada standard which almost certainly will contain additional "standard" packages, even if there is little or no change in the base language. What many people do not understand about the standards process is that a formal standard is expected to be the codification of an emerging consensus. Ada has not been an execption to this rule--anyone can propose a new standard "de novo", but for the standard to be approved, there needs to be a defined community representing several different constituencies which feels that a standard in this area is required, and a consensus needs to be developed within the community on a particular standard. There are two reasons why some useful packages were not in Ada 83. There was an intentional bias toward excluding interfaces that did not require "magic" from the compiler, but there were several areas such as complex types and numerics where this bias did not apply. Why weren't they included then? Well look at the work of the NUMWG and later NRG. It took about a decade to define those packages well enough to standardize them. In the process, the NUMWG did a great deal of research and development in the area of algorithms. Similar work was done by the IEEE in developing the IEEE floating point standards. There was a community, it recognized the need, but it took a lot of work to reach a point where a standard was appropriate. So it seems a little silly to condemn Ada 83 for not including standards in these areas, when, especially in the area of error bounds on trig functions, Ada 83 was the driving force behind the work. (And the work did result in several standards. Ada 95 incorporated this work into the RM, and the various additonal numerics standards were allowed to lapse. The same thing applies now in the area of class libraries. It would have been nice to release Ada 95 with a standard class library, but a number of fundamental descisions in implementing such a library depend on details of the language that were not determined until late in the standardization process. I think the line was drawn at a very practical point. All of the Annexes that made it into Ada 95 were ready for standardization when the language was, although one of MY major concerns was that the number of Annexes would spread potential reviewers way too thin, and some of the Annexes would not receive the necessary amount of attention. In fact, some boners did slip through--look at G 1.1(55) which gets complex exponmentiation wrong--fortunately in an implementation permission. But in the end, the Ada 95 RM was a much higher quality document than the Ada 83 RM, and the Ada 83 RM was very good for a programming language standard. So if you want a set of class libraries for Ada, work on one of the existing libraries out there, write your own, or help to decide between different approach so that there is an emerging consensus. If there is a need and a consensus, then a standard can be initiated, whether as part of the next revision of Ada, or as a separate effort. I just happen to think that we are in the very early stages of that process with respect to Ada class libraries. (Bindings to class libraries in other languages is a very different animal, and one that I personally don't find interesting.)