From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Subject: Re: Preprocessors & the "spirit of Ada"
Date: 26 Dec 89 21:59:14 GMT [thread overview]
Message-ID: <7522@hubcap.clemson.edu> (raw)
In-Reply-To: 1989Dec22.235145.3195@ico.isc.com
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
prev parent reply other threads:[~1989-12-26 21:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1989-12-12 20:30 Dave Emery's proposal for Ada preprocessor Daniel Lee
1989-12-13 14:31 ` arny.b.engelson
1989-12-13 22:23 ` Michael Schwartz
1989-12-14 14:47 ` William Thomas Wolfe, 2847
1989-12-14 15:11 ` Steve Tynor
1989-12-14 20:40 ` William Thomas Wolfe, 2847
1989-12-22 23:51 ` ending a language war (was "proposal for Ada preprocessor") Dick Dunn
1989-12-23 13:04 ` Markku Sakkinen
1989-12-26 21:59 ` William Thomas Wolfe, 2847 [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox