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=2.6 required=5.0 tests=BAYES_20,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!sol!emory!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: Preprocessors & the "spirit of Ada"
Message-ID: <7522@hubcap.clemson.edu>
Date: 26 Dec 89 21:59:14 GMT
References: <1989Dec22.235145.3195@ico.isc.com>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From rcd@ico.isc.com (Dick Dunn):
>>    ...Classic 
>>    Ada, a preprocessor used to generate Ada code which implements the 
>>    object-oriented mechanisms of inheritance and dynamic binding...
> 
> I hadn't been aware of this, but I've known all along that C++ was done as
> a preprocessor.  The thing that I hadn't realized, that's important, is
> that it's apparently within the spirit of proper Ada usage to construct a
> language variant with a preprocessor!   [...proposes C++-to-Ada...]
> 
%   - It's OK, in which case it seems that one could make arbitrary changes
%     to "Ada" by this approach--as long as the preprocessor output is Ada.
%   - It's entirely out of the spirit of Ada, in which case I wonder why
%     "Classic Ada" is acceptable.
%   - It's not OK but "Classic Ada" is OK, in which case I wonder where the
%     dividing line lies.

   I personally would consider the use of a C++-to-Ada preprocessor for 
   the development of new code to be entirely out of the spirit of Ada.

   In my view, the dividing line is as follows:

      If you are a researcher seeking to experiment with new ideas in
      programming language design, then you can safely make arbitrary
      changes to Ada in the course of your research; Ada is a production
      programming language, and the development of ideas which would help 
      to further improve the Ada language is to be strongly encouraged.

      If you are a production programmer, it is acceptable to use a
      preprocessor as long as:

         1) The use of preprocessing techniques is limited to those
            situations in which specific, indispensable requirements
            cannot be satisfied using Ada alone, without incurring
            extraordinary and disastrous expenses.  

         2) The limitations of Ada which precluded its direct application
            to the project involved, and the nature and circumstances of
            preprocessor use, are reported directly to the Ada Joint 
            Program Office, along with any suggested Ada revisions which 
            would suffice to rectify the situation.  Reporting is not
            necessary if it is known that AJPO is well aware of the 
            specific preprocessor workaround being used and is working
            on the specific limitations which necessitated its use. 

   Keeping in mind the above guidelines, I would consider a C++-to-Ada
   translator to be legitimately useful only as a tool for the conversion
   of C++ software systems to Ada.  As described in the Ada Adoption Handbook
   (Foreman and Goodenough, CMU/SEI Technical Report ESD-TR-87-110, May '87),
   there are significant problems and issues to be considered before taking
   this approach.  Among others, there are:

      - Degree of translation: not all constructs in other languages
        can be translated automatically to Ada with complete accuracy.
        As Markku Sakkinen has pointed out, the undisciplined use of
        pointers would present considerable translation difficulties
        in the case of "hacking languages" such as C and C++.  Much
        manual effort will be required in order to detect and fix the
        areas in which automatic translation was difficult or impossible. 

      - Loss of software engineering benefits: the translated code will
        be harder to maintain than the original software, and harder to 
        maintain than a system designed and written in Ada from the start.

   Most importantly of all, automatic translation cannot make up for the
   lack of good software engineering practices in the original code.  This
   is often the fatal blow to the viability of the translation approach; a
   FORTRAN system replete with GOTOs will be at least as badly designed 
   upon translation into Ada.  Similarly, the undisciplined practices which 
   are common among the users of C and C++ would not simply vanish during the 
   translation process, and it may well be infeasible to seriously consider
   using the existing foreign-language system as a basis for anything other
   than a basis for a total redesign of the system.  If there are areas of
   the system which do happen to be well-written, though, pragma Interface 
   can be used in order to salvage those particular parts of the system.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu