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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.lang.ada
Subject: Re: Ada 9X objectives
Message-ID: <6695@hubcap.clemson.edu>
Date: 6 Oct 89 16:11:08 GMT
References: <4349@fy.sei.cmu.edu>
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From jbg@sei.cmu.edu (John Goodenough):
> no one yet knows what the likely changes might be, because the change 
> requests have not yet been analyzed against the stated goals of the 
> 9X process...

   I would tend to rather strongly doubt that any significant number 
   of the change requests appearing in the places I described will be 
   in conflict with the stated goals of 9X.

>     "to revise ANSI/MIL-STD-1815A to reflect current essential requirements
>     with minimum negative impact and maximum positive impact to the Ada
>     community.  The Ada 9X process is a revision and not a redesign of the
>     language and should be viewed as a natural part of the language maturation
>     process."  [From the Ada 9X Project Plan, January 1989]
> 
> In my opinion, this means the goal is to improve the usability of Ada, and
> this means fixing problems while not destabilizing the adoption process or the
> quality of Ada implementations.  How this can be done will be the subject of
> much discussion in the next few years, but major and widespread
> incompatibilities certainly are not consistent with the stated goals.

    Major and widespread incompatibilities which do not offer strong
    advantages would not be consistent, but where a strong advantage
    is to be gained (e.g., the ability to apply a high-powered multiple
    inheritance system), the magnitude of the positive impact would
    certainly overcome the possibility that an automatic translator
    might be required.  This is completely consistent with the 
    language maturation process, and corresponds directly to the 
    continuing maturation of the software engineering process. 

    My contention is that if 9X does not track the state of the art
    with respect to the software engineering process, then the adoption
    process will be "destabilized" completely, since more modern languages
    which provide better support for the software engineering process
    will be used instead.  THAT is inconsistent with Ada 9X objectives. 

> It is certainly premature to suggest that some kind of automatic 
> translator will be required.  In fact, I think most people involved 
> with the effort would be appalled if something called an "automatic 
> translator" from Ada 83 to Ada 9X was required.

    What I am suggesting is that it would be an extremely good idea to
    assume that this will be the case.  If not, fine; but given the amount
    of evolution which has occurred with respect to the language capabilities
    needed in order to provide support for the modern software engineering 
    process, I would certainly consider it a good idea to be prepared to use 
    an automatic 83 => 9X translator as part of the conversion. 
     

    Bill Wolfe, wtwolfe@hubcap.clemson.edu