Ada95 Should be a Multivolume ISO Standard

Ada95 Should be a Multivolume ISO Standard

[Robert C. Leif, Ph.D.]

From: Robert C. Leif, Ph.D.
Vice President, Ada_Med

Date: 30 September, 1996

On   Sun, 15 Sep 1996 06:27:06 -0400
Professor  Robert Dewar <dewar@CS.NYU.EDU>
Responded to my note "Ada95 Should be a Multivolume ISO Standard"
Subject: Re: Ada95 Should be a Multivolume ISO Standard

Since this text involves quotes from two individuals, I (Robert Leif) will
indicate the author by the first letter of his last name being placed at the
beginning of the quoted paragraph. Leif => L; Dewar => D; My new comments
will NOT be in quotes.

L. Introduction: Professor Dewar and I have different views on the
advisability of making interim changes to the Ada Standard.  I suspect that
we are looking at the problem from two different prospectives. He is viewing
it, as a superb software engineer, and I am looking at it from a business
perspective.  I believe the vast majority of the readers of this note would
very much like to see greater commercial usage of Ada.  I hope my arguments
lead to a way to accomplish this without sacrificing the quality of Ada's
design.

Robert Leif wrote:
L. suggested, "The first step is to change Ada 95 from a single to a
multivolume ISO standard. The specification of Ada presently is based on the
waterfall model and occurs at periods greater than a decade. A multivolume
standard would permit the classic software approach of divide and conquer.
The spiral mode, which is the method of choice for most software
development, should be applied to Ada."

L. "The second step is to employ some standard's group, such as the IEEE, to
place its imprimatur on Provisional changes to Ada. I define  Provisional
to mean, this is our present design; but, we can  NOT guarantee that it will
stay in its present form. Experience may require that it be changed."

L.  "My personal choice for the standard's group is ACM SigAda. I quite well
realize that the ACM is presently not a standards organization. However, the
ACM SigAda has the great advantage of being composed of Ada enthusiasts."

Robert Dewar replied
D. "I strongly disagree with Bob Leif's suggestion. Yes, ACM SigAda is indeed
a great source of Ada enthusiasts. It is thus a good source of ideas for
language changes, and indeed during the Ada 95 process, many of the
suggestions for change originated from the language issues working group
of SigAda."

D. "However, it is not a suitable group at all for generating formal changes
to the standard, since this is an activity that requires more than
enthusiasm. It requires a substantial expenditure of time (not something
SigAda volunteers are likely to be able to provide), and a lot of
experience in language design, and a VERY detailed knowledge of the
semantic issues in Ada."


L. My reason for suggesting SigAda was that it was an Ada group; rather
than, ANSI or the IEEE, where one could not be sure who would be selected to
approve the provisional standard.  I could live with the Ada Resource
Association (ARA)  if it was, as originally, open to all Ada enthusiasts or
to a joint ARA and ACM SigAda  Provisional Standards Committee.  If AJPO or
a successor organization with similar functions exists, it could also
provide a member or two of this Provisional Standards Committee.

L. As far as the capacity of ACM SigAda to create an Ada Provisional
Standards Committee, I suspect that virtually all of the Ada experts who
would be appropriate to pass on Provisional Standards are members of ACM SigAda.


D. "The whole idea of a multi-volume standard for Ada is a bad one. it is
a recipe for changes getting into the language without adequate study
and care."

D. "Much better is to keep the entire process of developing extensions to
Ada informal, as has been done very successfully with other languages
(note that C++ is not yet even a single volume ISO standard!)"

L. C++ now has enough flavors to hopefully fade away into its well deserved
oblivion.  I wanted an intermediate group to insure that we do not over a
period of 12 years develop proprietary extensions.

L. It must be noted, that we have had the painful experience of having
available a technology superior to its competitors, Ada 83, that achieved
minimal commercial acceptance.  I believe one of the significant causes for
this lack of acceptance was the poor fit with commercial GUIs like Microsoft
Windows and X Windows.  The absence of a callback did us in.  I want to
emphasize that the lack of a callback was NOT a design mistake.  A reputable
group of software engineers can not be expected to anticipate the design
choices of others who work on different languages. The fault was in the
process.
L. When a significant problem, such as commercial windowing software,
appears, there should be a mechanism short of a complete review of the
language to institute change.  I also believe that a mechanism should be
developed to permit new annexes to be added to the standard. Otherwise,
other groups can define the equivalent of new annexes and have them approved
without going through ISO/IEC JTC/SC22 Working Group 9 (WG9).

L. After a provisional standard or Annex has been in use for some reasonable
period, for instance two years, WG9 could formally incorporate it into the
appropriate volume of the ISO Ada standard, or suggest changes including to
wait until the next complete review of Ada, or reject the provisional
standard or Annex.


D. "Let's discuss ideas for changes, a good example is Tuck's with type
suggestion for solving the circular reference problem, agree on possible
approaches, and then prototype and experiment with these ideas using GNAT
(that's one of the things GNAT is intended to enable!)"

L. Absolutely!  I would hope that GNAT would permit researchers to create
prototype extensions and changes to Ada that would provide the empirical
data needed for the next major review of the language. This in itself would
justify the DoD's expenditure for GNAT.

D. "Then if an idea seems like it is reasonable and has consensus, it can
be developed as an informally agreed on extension by the various vendors,
which will allow us to investigate possible implementation problems."


L. I think what Robert Dewar described above is a second source agreement.
This is the accepted practice in the semiconductor industry.  I have nothing
against second source agreements, as a first step.  However, I believe that
after a reasonable time, it would be more in keeping with current
standardization practices to have a public group create a provisional standard.


D. "If there are no such problems, then eventually the feature may find its
way into the next version of the language, or it may still not, because
the whole point of a language revision is to study the coherence of
various possible features. if all the good ideas for Ada 9X had been
added to Ada 83 one by one, we would have a horrendous mess on our hands."

L. Probably not. There are parts of Ada that are not strongly coupled for
example
Annex B: Interface to Other Languages, Package Interfaces Functions on
Unsigned_n and the ability to have access-to-subprogram types be an argument
to another subprogram.

L. However, I wish to very strongly emphasize that I am not asking for major
changes that are strongly coupled to the rest of the language; but only,
reasonable additions and minor fixes.  I believe that there has to be a
language development process that is neither a waterfall nor bottom up.  I
strongly believe that the language should NOT be defined as what the chief
operating officer or owner of the compiler company determines this minute.
However, I do not wish Ada to be cast in stone for ten to twelve years.

L. What I have suggested is a constrained spiral model.  Changes to the Ada
Specification will still have to be approved by ISO WG9.  The  specification
of a language is a software process and should be covered by the same
software engineering techniques employed to develop and maintain any other
major software artifact.   No other software artifact has the rule that
nothing can be changed during a decade of maintenance.

Robert C. Leif, Ph.D.
Vice President Ada_Med
Tel. & Fax (619) 582-0437
e-mail rleif@cts.com

Re: Ada95 Should be a Multivolume ISO Standard

[Richard A. O'Keefe]

I simply note that POSIX.5 was not developed as an amendment
to the Ada standard and didn't need to be.  (If POSIX.5 is the
Fortran binding and not the Ada one, please correct me.  I don't
have either yet.)

There is already a ton of good stuff in Ada.
If we want standard interfaces to other things, they can be separate
standards, just as POSIX.1 is not in the C standard, but is a separate
standard.  CORBA is not in the C standard.  X11 is not in the C standard.
PHiGS is not in the C standard.  &c.

>L. However, I wish to very strongly emphasize that I am not asking for major
>changes that are strongly coupled to the rest of the language; but only,
>reasonable additions and minor fixes.

There is already a mechanism in place for minor fixes.
I note that the C standard follows the same model:  one submits
Defect Reports and binding Interpretations are issued.

Additions can be separate standards that provide _interfaces_ that are
compatible with Ada.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada95 Should be a Multivolume ISO Standard

[Robert Dewar]

A short postscriopt here. Bob Leif says

"L. Introduction: Professor Dewar and I have different views on the
advisability of making interim changes to the Ada Standard.  I suspect that
we are looking at the problem from two different prospectives. He is viewing
it, as a superb software engineer, and I am looking at it from a business
--More--perspective.  I believe the vast majority of the readers of this note wo
very much like to see greater commercial usage of Ada.  I hope my arguments
lead to a way to accomplish this without sacrificing the quality of Ada's
design."


This is an inaccurate characterization of my views. I am the CEO of one of
the very few companies that is dedicated to the commercial success of Ada.
My view are entirely motivated from a business point of view, I think
a shifting standard for Ada, which involved the incorporation of inevitably
less well reviewed extensions would be damaging from a business point of view.

Re: Ada95 Should be a Multivolume ISO Standard

[Kevin D. Heatwole]

In article <9610011027.AA12679@nile.gnat.com>, Robert Dewar
<dewar@GNAT.COM> wrote:
>This is an inaccurate characterization of my views. I am the CEO of one of
>the very few companies that is dedicated to the commercial success of Ada.
>My view are entirely motivated from a business point of view, I think
>a shifting standard for Ada, which involved the incorporation of inevitably
>less well reviewed extensions would be damaging from a business point of view.

As an employee of another small company which is pouring (or is that 
"pooring" :-)) its heart and sole into making a world-class Ada95 compiler, 
I wholeheartedly agree with Dr. Dewar on this one.  I have seen nothing yet 
that suggests that Ada95 is broken badly enough to require significant 
changes to the current standard.  Those few areas that are legitimately 
broken can and should be dealt with through the existing mechanism of 
issuing a binding AI to the standard and hopefully implementing an ACVC test 
to check for conformance by all validated Ada compilers to this binding AI.

To me, it is important that all commercially available Ada compilers 
implement the same language.  It doesn't seem to be in anybody's best 
interests to have each compiler implement some dialect of Ada95 just to 
make some person's program easier to write or to "fix" some part of the 
language that a specific compiler vendor feels is "broken".  I already have 
significant concerns that GNAT will implement such new tweaks to the 
language creating a bunch of GNAT-Ada code to be developed that won't 
easily be reuseable with other Ada compilers.

About 10 years ago, I spent around 3 months implementing a design on the 
Rational R1000 Environment.  All went very well on the Rational machine, 
but when I ported the code to the target machine (using an Alsys compiler), 
I found that the Alsys compiler caught an error in my use of generic formal
parameters. This error caused me significant effort and a major 
reimplementation to get around the error.  When I reported this bug to
Rational, the engineer commented that he knew about this incompatibility,
but that he felt that Ada was broken here and had chosen to implement a 
relaxation of the rules in this case. In other words, it was a conscious 
decision by a compiler vendor to allow a dialect of Ada into their compiler.
This cost my project some real dollars.

Anyway, as an Ada programmer, I can accept that no vendor's Ada compiler 
will accept all legal Ada programs and reject all illegal ones.  Ada is just 
to complex to expect a perfect compiler, but hopefully all vendors will make 
every effort to produce a perfect compiler.  Dribbling in potentially 
ill-thought out enhancements to the language is a sure formula to create a 
tower of Babel.

Note that I think it is perfectly legitimate for Ada compilers to implement
non-standard features for various reasons, but I hope the compiler vendor 
that choose to do so, will make it painfully obvious to the user that they are 
no longer writing Ada but some pigeon Ada dialect (like requiring the use of
a specific compiler switch to enable the dialect and hopefully generating
appropriate warnings for non-standard Ada uses).

Kevin Heatwole
OC Systems, Inc.

Re: Ada95 Should be a Multivolume ISO Standard

[Larry Kilgallen]

In article <9610011027.AA12679@nile.gnat.com>, Robert Dewar <dewar@GNAT.COM> writes:
> A short postscriopt here. Bob Leif says
> 
> "L. Introduction: Professor Dewar and I have different views on the
> advisability of making interim changes to the Ada Standard.  I suspect that
> we are looking at the problem from two different prospectives. He is viewing
> it, as a superb software engineer, and I am looking at it from a business
> --More--perspective.  I believe the vast majority of the readers of this note wo
> very much like to see greater commercial usage of Ada.  I hope my arguments
> lead to a way to accomplish this without sacrificing the quality of Ada's
> design."
> 
> 
> This is an inaccurate characterization of my views. I am the CEO of one of
> the very few companies that is dedicated to the commercial success of Ada.
> My view are entirely motivated from a business point of view, I think
> a shifting standard for Ada, which involved the incorporation of inevitably
> less well reviewed extensions would be damaging from a business point of view.

I have endured Ada83 limitations in making commercial software since 1988.

I would like to endure Ada95 limitations in making commercial software
at least as long.

Diversity in the programming language supported by compilers I buy
is a liability.  In contrasting Ada to Pascal (my second choice) I
am beginning to believe that the stronger typing is less compelling
than the stronger standard (i.e., honored by compiler vendors).

Even if extensions are perfectly reviewed, unless they are available
from all my chosen vendors, they are not useful.  To whatever extent
just a subset of my chosen vendors spend time implementing them, they
are in fact counter-productive since they distract those vendors from
making other improvements like the IDE or the optimizer or the quality
of error messages or lowering the price.

Larry Kilgallen