billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/27/89)
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