* Re: Dave Emery's proposal for Ada preprocessor
@ 1989-12-12 20:30 Daniel Lee
1989-12-13 14:31 ` arny.b.engelson
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Lee @ 1989-12-12 20:30 UTC (permalink / raw)
We are developing a commercial Ada-based tool (expert system tool in
particular) which has to run on multiple platforms possibly on
multiple compilers on the same hardware. We found that the lack
of Ada tool similar to cpp makes it very hard to maintain portable Ada code
across multiple platforms, and yet Ada is designed for portability.
Currently, we are using cpp on a Sun to preprocess the master Ada
source with cpp macros embedded (e.g. #if, #endif, etc.). Then, we preprocess
it using cpp. First, we defined app as follows:
/lib/cpp $1 $2 $3 $4 $5 $6 $7 $8 $9 | grep -v "^#"
Then, we do the following:
app -DVERDIX foo.a.master > foo.a or
app -DVMS foo.a.master > foo.ada
The problem with this is that foo.a.master is still not a compilable
Ada file and has to be preprocessed manually while its C equivalent
is a direct input to a C compiler. I agree with Dave that if such
thing as cpp is added to Ada, it should be part of STANDARD Ada
so that only a single source file has to be maintained.
Danile Lee
Inference Corporation
sdl@inference.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Dave Emery's proposal for Ada preprocessor
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
0 siblings, 2 replies; 9+ messages in thread
From: arny.b.engelson @ 1989-12-13 14:31 UTC (permalink / raw)
In article <8912122030.AA05794@Herbrand.Inference.Com> sdl@herbrand.Inference.Com (Daniel Lee) writes:
>Currently, we are using cpp on a Sun to preprocess the master Ada
>source with cpp macros embedded (e.g. #if, #endif, etc.). Then, we preprocess
>it using cpp.
>
> Danile Lee
> Inference Corporation
> sdl@inference.com
You're not the only one doing this. I have seen folks here also using the
C preprocessor to maintain Ada code for more than one target. This is a
pretty good indication that we need a standard Ada preprocessor. You can
argue for or against such a thing based on philosophical reasons, but if
experienced, competent programmers are going as far as using cpp, we really
ought to create a standard Ada preprocessor.
-- Arny Engelson att!wayback!arny
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Dave Emery's proposal for Ada preprocessor
1989-12-13 14:31 ` arny.b.engelson
@ 1989-12-13 22:23 ` Michael Schwartz
1989-12-14 14:47 ` William Thomas Wolfe, 2847
1 sibling, 0 replies; 9+ messages in thread
From: Michael Schwartz @ 1989-12-13 22:23 UTC (permalink / raw)
We have used RCS for this purpose; but I have to admit conditional
compilation would have aided in maintenance.
Michael
--
-----------------------
schwartz@pogo.den.mmc.com "Expect everything ...
mschwartz@mmc.com and the unexpected never happens."
ncar!dinl!schwartz --the phantom tollbooth
DISCLAIMER: The opinions expressesed are not necessarily those of my
employer or myself.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: proposal for Ada preprocessor
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-22 23:51 ` ending a language war (was "proposal for Ada preprocessor") Dick Dunn
1 sibling, 2 replies; 9+ messages in thread
From: William Thomas Wolfe, 2847 @ 1989-12-14 14:47 UTC (permalink / raw)
From arny@cbnewsl.ATT.COM (arny.b.engelson):
> You can argue for or against such a thing based on philosophical reasons,
> but if experienced, competent programmers are going as far as using cpp,
> we really ought to create a standard Ada preprocessor.
A standard preprocessor would have the advantage of being standardized,
but would suffer the disadvantage that compiler optimizations are not
possible where the compiler has no knowledge of high-level semantics,
which is a major reason not to simply codify the preprocessing practice.
One example of where this would appear inappropriate would be Classic
Ada, a preprocessor used to generate Ada code which implements the
object-oriented mechanisms of inheritance and dynamic binding. It
would seem that substantial optimizations could be performed if the
compiler had knowledge of the inheritance graph, but not if this
knowledge is kept hidden from the compiler by a preprocessor.
In addition, a compiler can simply have a "preprocessing" pass as its
first phase if it so chooses; it would therefore seem that we would lose
nothing by defining our features as part of the language rather than as
part of the input to a separate preprocessor.
These are of course "philosophical" arguments, but I really think the
use of preprocessors should be limited to:
- those who are doing programming language research
- cases in which a language's revision cycle is so lengthy
that important advances are not incorporated within a
reasonable period of time (and this is certainly the
case with the present Ada 10-year revision cycle, which
I would like to see cut in half).
From emery@D74SUN.MITRE.ORG (David Emery):
> Bill Wolfe sez:
> > [standardization of symbols like the enumerations in SYSTEM.NAME
> > should be ]
> > Appropriately handled in the package which provides the binding to
> > the operating system involved. OS bindings must also be standardized,
> > and this is taking place; e.g., the IEEE 1003.5 Ada binding to Posix.
>
> First, there are often options in a program which are not bound to the
> operating system. One example that I've seen used very effectively
> occurs in the C source for Nethack, where features may be included or
> excluded at compile time by defining or undefining certain symbols.
> These features include things like different types of monsters, as
> well as support for system things, such as compressing save files.
I'm not familiar with Nethack (in fact, I try to stay away from
anything remotely associated with hacking), but it would seem that
you could do this simply by designing the software system to "with"
a "Options_Desired" package specification which would be edited by
the user to reflect the desired optional features; this would keep
the definitions concentrated in a standard place.
It seems offhand that the effect of testing whether symbols are
defined or undefined can be automatically accomplished by defining
an enumerated type containing all the symbol names, creating a boolean
array indexed by that enumerated type, and initializing it with the
appropriate values by named association. Then the user would simply
edit the named associations to set desired options to True and others
to False. Perhaps you had more in mind than just checking for "defined"?
> Second, as Technical Editor for IEEE 1003.5 POSIX Ada Binding, I see
> several instances in our binding where conditional compilation would
> be very useful to an applications programmer, particularly one trying
> to write portable software. This is particularly true of the
> execution time symbolic constants, such as the C symbols
> _POSIX_NO_TRUNC and _POSIX_VDISABLE (defined in IEEE P1003.1-1988),
> and depending on the application, may also be true of the compile time
> symbolic constants, such as _POSIX_JOB_CONTROL.
Again, it seems to me that by a suitable definition of the binding,
these things could be accomplished using an existing mechanism.
Assuming that, for example, POSIX_NO_TRUNC is a boolean variable
whose value changes at run-time and depends on the identity of the
process requesting its value, why not simply provide a function
in the binding which finds out the identity of the caller (being
an operating system binding, it should be able to do this) and
returns the appropriate value to the caller?
(Disclaimer: not being the Technical Editor of the Posix binding,
it's entirely possible that there are major flaws in my suggestion;
I'm simply trying to isolate the fundamental reasons involved...)
> "Ultimate standardization", even of operating system names, is a long
> way away. I don't see anyone racing around trying to standardize such
> things, either.
Tell me about it. One particularly ludicrous example: one would think
that compiler vendors would want to make it easy for you to write
software which is portable across THEIR line of Ada compilers, if
not anyone else's. Therefore, one would expect the compiler vendors
to supply definitions of SYSTEM.NAME which enumerate all the hardware
platforms for which compilers exist in the vendor's product line, so
that developers could write software which targets all the platforms
for which that vendor markets Ada compilers. If the vendor wanted to
frustrate moving to another vendor's compiler environment, the exact
names used in the enumeration could differ from those used by all other
known vendors. I know of at least two major compiler vendors, with
product lines spanning dozens of platforms, whose definition of
SYSTEM.NAME enumerates exactly one platform: the machine on which
the compiler at hand happens to run!!!
> I don't believe that it's worth waiting for,
> particularly since it won't solve all the problems.
I'll agree that it's not worth *waiting* for... it's worth *PUSHING* for!!!
Still trying to isolate why it "won't solve all the problems", though...
Bill Wolfe, wtwolfe@hubcap.clemson.edu
P.S. I could kick myself for not putting in a 9X suggestion that
the rule about all field names being distinct be set up such
that one can do variant records whereby each of the mutually
exclusive variants are identically named... that rule makes
us add contrived suffixes to the field names just to get them
past the compiler, which would appear to be very nonproductive.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: proposal for Ada preprocessor
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
1 sibling, 1 reply; 9+ messages in thread
From: Steve Tynor @ 1989-12-14 15:11 UTC (permalink / raw)
In article <7423@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
...
> It seems offhand that the effect of testing whether symbols are
> defined or undefined can be automatically accomplished by defining
> an enumerated type containing all the symbol names, creating a boolean
> array indexed by that enumerated type, and initializing it with the
> appropriate values by named association. Then the user would simply
> edit the named associations to set desired options to True and others
> to False. Perhaps you had more in mind than just checking for "defined"?
What about the cases where disabling a feature should prevent 'with'ing a
package? (e.g. don't 'with' a DEBUG_TRACE package in a released version) -
Your method will prevent calls to the trace procedures, but the DEBUG_TRACE
package would still be linked in to the executable (ignoring potential linker
optimizations that might recognize that none of that package's code is actually
called).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Never put off until tomorrow what you can avoid altogether.
Steve Tynor
Georgia Tech Research Institute
Artificial Intelligence Branch
tynor@prism.gatech.edu
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: proposal for Ada preprocessor
1989-12-14 15:11 ` Steve Tynor
@ 1989-12-14 20:40 ` William Thomas Wolfe, 2847
0 siblings, 0 replies; 9+ messages in thread
From: William Thomas Wolfe, 2847 @ 1989-12-14 20:40 UTC (permalink / raw)
From tynor@prism.gatech.EDU (Steve Tynor):
> What about the cases where disabling a feature should prevent
> 'with'ing a package? (e.g. don't 'with' a DEBUG_TRACE package
> in a released version) - Your method will prevent calls to the
> trace procedures, but the DEBUG_TRACE package would still be
> linked in to the executable (ignoring potential linker optimizations
> that might recognize that none of that package's code is actually called).
No, in fact these linker optimizations are relied upon very heavily
in Ada. Consider a generic abstract data type -- the idea is to
provide as much functionality in that ADT as can reasonably be
expected to ever be required by any of the users. Any functionality
which can be expressed generically is an excellent candidate to be
included in the package. Now if we could not rely upon these linker
optimizations, then ADT developers would go crazy trying to keep
5000 variations of the same package and ADT users would go crazy
trying to select the package having exactly the set of operations
they will use and no more. Obviously this is ridiculous -- both
developer and user rely instead upon the fact that the compiler/
linker/etc will automatically trim away anything not referenced
by the user. To assume otherwise is inconceivable.
Bill Wolfe, wtwolfe@hubcap.clemson.edu
^ permalink raw reply [flat|nested] 9+ messages in thread
* ending a language war (was "proposal for Ada preprocessor")
1989-12-14 14:47 ` William Thomas Wolfe, 2847
1989-12-14 15:11 ` Steve Tynor
@ 1989-12-22 23:51 ` Dick Dunn
1989-12-23 13:04 ` Markku Sakkinen
1989-12-26 21:59 ` Preprocessors & the "spirit of Ada" William Thomas Wolfe, 2847
1 sibling, 2 replies; 9+ messages in thread
From: Dick Dunn @ 1989-12-22 23:51 UTC (permalink / raw)
A posting from Bill Wolfe suggested to me that there might be a way to end
one language war...Bill had mentioned:
> ...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!
So...we know that we can preprocess C++ -> C. I suspect one can preprocess
to get C -> Ada. Combine the two and you've got a tool analogous to
"Classic Ada" except that its input looks like C++. C++ programmers can
create Ada programs without having to learn nasty old Ada, and they can
stop complaining about what Ada lacks. Ada partisans can stop flaming C++
folk for being nasty hackers who refuse to see the clear superiority of
the One True Language.
What's wrong with this picture?
Being serious for a moment (Bill W says programming is serious), I see
three possibilities for the above scenario:
- 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.
--
Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...Mr. Natural says, "Use the right tool for the job."
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ending a language war (was "proposal for Ada preprocessor")
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 ` Preprocessors & the "spirit of Ada" William Thomas Wolfe, 2847
1 sibling, 0 replies; 9+ messages in thread
From: Markku Sakkinen @ 1989-12-23 13:04 UTC (permalink / raw)
In article <1989Dec22.235145.3195@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
- ...
-So...we know that we can preprocess C++ -> C. I suspect one can preprocess
-to get C -> Ada. Combine the two and you've got a tool analogous to
-"Classic Ada" except that its input looks like C++. [...]
I am afraid the semantics of C (and C++) is much too nasty for translation
to any high-level language. Just think about its wild ways with pointers!
Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Preprocessors & the "spirit of Ada"
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
1 sibling, 0 replies; 9+ messages in thread
From: William Thomas Wolfe, 2847 @ 1989-12-26 21:59 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1989-12-26 21:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` Preprocessors & the "spirit of Ada" William Thomas Wolfe, 2847
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox