10-year Ada Language Standard Revision Cycle

10-year Ada Language Standard Revision Cycle

[Bill Wolfe]

From comp.std.internat article <9310@shlump.nac.dec.com>, 
  by lasko@regent.dec.com (Tim Lasko, Digital Equipment Corp., Westford MA):
> 
> In re the discussion on 5- vs. 10-year cycles, the ISO-IEC rule is "5": From
> the  ISO-IEC Directives Part 1, Procedures for the technical work, clause
> 2.7.1:
> 
% "Every International Standard shall be reviewed at least every five years
% by the technical committee or sub-committee responsible for it, in order to
% decide by a majority vote of the P-members voting whether it should be
% confirmed, revised, or withdrawn."


   I had heard at the Ada 9X discussion at the Eighth Annual National
   Conference on Ada Technology that the next revision would take place
   in TEN years due to 10 years being the standard ISO revision cycle... 
   are there any knowledgeable people who could comment?

   (If a five-year cycle is indeed in accordance with the internationally
     accepted and agreed-upon norm, I strongly believe that Ada should be 
     on a five-year revision cycle and *NOT* a ten-year revision cycle..)


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
  

Re: 10-year Ada Language Standard Revision Cycle

[Robert I. Eachus]

In article <8412@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:

 >  I had heard at the Ada 9X discussion at the Eighth Annual National
 >  Conference on Ada Technology that the next revision would take place
 >  in TEN years due to 10 years being the standard ISO revision cycle... 
 >  are there any knowledgeable people who could comment?
 >   (If a five-year cycle is indeed in accordance with the internationally
 >    accepted and agreed-upon norm, I strongly believe that Ada should be 
 >    on a five-year revision cycle and *NOT* a ten-year revision cycle..)

 >    Bill Wolfe, wtwolfe@hubcap.clemson.edu

    The rule in both the ANSI and ISO communities is that a decision
to affirm, revise, or abandon has to be made five years after a
standard is adopted, and that a standard which has been neither
affirmed or superceded within ten years lapses.

    In 1988 (five years after the 1983 Ada ANSI standardization) the
Ada Board recommended that a new standard be developed.  This Ada 9X
process recommendation was very close to what has developed and was
about 30 pages in final form...quite a detailed recommendation.

     The ISO Ada standard was adopted in 1987 (a pointer to the ANSI
and French standards), so it is not due for review unitl 1992, and
will not lapse until 1997.  Since the ISO standard technically
supercedes the ANSI standard in this country, the real lapse date is
1997, but I hope we have at least a proposed new ANSI standard before
1993, and an adopted standard well before 1997.  In fact we could be
starting on the next revsion by then.  (Sigh...)

     My current guess (not my preferences, just a guess as to what
will happen) is that the first revision will be a very minor one, with
the largest changes being things like replacing ASCII with Latin-1,
allowing literals from other character sets, unsigned types (but not
as predefined integer types), dynamic prioities, and better support
for entry families.  The following revison can deal with evolution.

     There may be some extensions to make OOP easier, but don't expect
much in the way of changes.  Just the ability to do what you can do
already in a much more elegant way.  (Which is a lot.  The only major
feature not directly supported in Ada is multiple inheritance, and
overload resolution makes that a big can of worms.)

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Ada Language Revision Cycle

[William Thomas Wolfe, 2847]

From eachus@aries.mitre.org (Robert I. Eachus):
>      My current guess (not my preferences, just a guess as to what
> will happen) is that the first revision will be a very minor one, with
> the largest changes being things like replacing ASCII with Latin-1,
> allowing literals from other character sets, unsigned types (but not
> as predefined integer types), dynamic prioities, and better support
> for entry families.  The following revison can deal with evolution.

   What would be the rationale for deferring evolution another 5 years?

   It seems to me that it is at least as important to modernize software
   technology as it is to modernize hardware technology (e.g., aircraft)!

   The area in which object-orientation will provide the maximum payoff,
   that of management information systems, is of particular importance
   to the DoD right now -- witness the spare parts scandals!  Therefore I
   consider it especially important that object-orientation be addressed.
  
>      There may be some extensions to make OOP easier, but don't expect
> much in the way of changes.  Just the ability to do what you can do
> already in a much more elegant way.  (Which is a lot.  The only major
> feature not directly supported in Ada is multiple inheritance, and
> overload resolution makes that a big can of worms.)

   As I mentioned in an earlier article, there is recent work in the
   area of combining types, inheritance, and prototyping (one reference
   being "Object Specialization", ACM Transactions on Information Systems,
   April 1989; I am in the process of investigating others) which basically
   eliminates both the need and the desire for multiple inheritance.  Though
   this particular paper isn't easy reading (it helps a LOT to translate the
   Smalltalk notation into a more Ada-like notation), the ideas in it seem
   to be both analytically and intuitively quite strongly appealing.  With
   minor adjustments, these mechanisms could fit right into Ada very nicely!!

   Five years from now is plenty of time to get an extremely strong proposal
   together.  If Ada *will* be open to such a change in five years, then it
   will find itself very well-positioned to enter the next century.  But what
   about the five years between now and then?


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: 10-year Ada Language Standard Revision Cycle

[Alex Blakemore]

In article <EACHUS.90Mar17181052@aries.aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes:
>      There may be some [Ada] extensions to make OOP easier, but don't expect
> much in the way of changes.  Just the ability to do what you can do
> already in a much more elegant way.  (Which is a lot....

>  The only major [OOP] feature not directly supported in Ada is multiple inheritance,

Are you serious?  What about single inheritance?  The inheritance provided by
derived types is close to *useless* since you cant add fields/attributes to
the new type.  They provide strong typing and a way to change representations.
Not to mention polymorphism (different than overloading) and dynamic binding.

-------------------------------------------------------------------------
Alex Blakemore             blakemore@software.org          (703) 742-7125
Software Productivity Consortium   2214 Rock Hill Road Herndon, VA  22070
------------------------   Eschew Obfuscation !!! -----------------------

Re: Ada Language Revision Cycle

[Robert I. Eachus]

In article <8423@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

>  From eachus@aries.mitre.org (Robert I. Eachus):
> >      My current guess (not my preferences, just a guess as to what
> > will happen) is that the first revision will be a very minor one...

>     What would be the rationale for deferring evolution another 5 years?

   Gee, I thought I said that this is what I think will happen, not
what I want.  Our town did some things at last week's town meeting
that I didn't like (and some that I did).  I could usually call the
vote well before it occured, but in many cases the votes were strongly
influenced by people's attitude toward those who were the principal
spokespeople for either side rather than any feature of the proposal
itself.  The same thing seems to be happening on Ada 9X.  There is a
groundswell developing to fix a few small things NOW, and leave the
rest til later. (Of course, not everybody agrees on the "few small
things." :-)

>     It seems to me that it is at least as important to modernize software
>     technology as it is to modernize hardware technology (e.g., aircraft)!

     No disagreement.

>     Five years from now is plenty of time to get an extremely strong
>     proposal together.  If Ada *will* be open to such a change in
>     five years, then it will find itself very well-positioned to
>     enter the next century.  But what about the five years between
>     now and then?

      It will probably take five years to get a good proposal
together.  I also think that that is a minimum time to study some of
these issues and come up with something that mixes cleanly with the
existing language.  So by all means, start now, I started last year. :-)
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Ada Language Revision Cycle

[Bill Wolfe]

eachus@aries.mitre.org (Robert I. Eachus) writes:
> in many cases the votes were strongly
> influenced by people's attitude toward those who were the principal
> spokespeople for either side rather than any feature of the proposal
> itself.  The same thing seems to be happening on Ada 9X.  

   I hope that the 9X process will be sufficiently open to ensure
   that all proposals will be considered on their own merits -- this
   sounds a lot like the "Not Invented Here" syndrome.

>       It will probably take five years to get a good proposal
> together.  I also think that that is a minimum time to study some of
> these issues and come up with something that mixes cleanly with the
> existing language.  So by all means, start now, I started last year. :-)

   In that case, we should organize into a working group to consider the
   issues together rather than inefficiently duplicating our individual
   efforts.  Probably the best way to do that would be to form an ACM
   SIGAda Working Group.

   I will take the first step: forming a list of potential members.  If
   you, the reader, are interested in participating in a potential ACM
   SIGAda Object-Oriented Working Group, please modify the following
   prototype response as appropriate and E-mail it back:

   ------------------------ Prototype... Cut Here ---------------------

                  ACM SIGAda Object-Oriented Working Group

      Your Name:  William T. Wolfe                  Member ACM?     Yes
      E-mail:     wtwolfe@hubcap.clemson.edu        Member SIGAda?  Yes
      Snailmail:  Department of Computer Science
                  Clemson University
                  Clemson, SC  29634-1906   USA

   ------------------------ Prototype... Cut Here ---------------------
      

   Bill Wolfe, wtwolfe@hubcap.clemson.edu