Re: Desirability of C++

["Robert I. Eachus" <rieachus@earthlink.net>]

"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.)