larry@VLSI.JPL.NASA.GOV (01/01/88)
--
If pre-processors or translators can be written for C to produce object-
oriented languages, then the same ought to be possible for Ada. Has (is)
anyone done this? What are the advantages and problems?
I can see at least two problems for users. Debugging of programs produced
by anything other than a compiler means your
you're looking at "ugly Ada" rather than the "super Ada" of
Objective-Ada/Ada++. This was one reason RatFor and company never caught
on widely.
Also, standardization might suffer. I suspect, however, that the various
super-Adas would be used only in experiments, and that useful features
would eventually find their way into Ada-1993.
Larry @ jpl-vlsibertrand@hub.ucsb.edu (Bertrand Meyer) (01/02/88)
Larry raised two points: 1 - Why can't compilers for OO languages generate Ada just as well as C; 2 - problems with preprocessors. (I have no competence on his third point, standardization) On point 1, C is better than Ada because it is at a lower level of abstraction. Many the features of C that I hate as a programmer are helpful when I use it as target language for a compiler. This includes features such as pointer arithmetic, side-effect returning functions, pointers to functions etc. Ada, on the other hand, has a strict notion of type and does not offer such low-level facilities. This makes it more conducive to the implementation of some modern software engineering techniques (with the exception of OO-programming), but less appropriate as target for a compiler. With C, the way we use it (as a portable assembly language), but at least the typing constraints of the language stand less in your way (although in practice it's not a piece of cake, if you want to use it as target for a serious OO language compiler, believe me). We have had many questions of the form ``Could you generate Ada from Eiffel?'', especially from prospects from the military-aerospace community. Our standard answer is that we could in principle, but we don't see any sound reason for doing it. Technically it does not make much sense; we would have to invent contorted compiling techniques, and in the end could only get a performance degradation as compared to our current C-based techniques. So the only reason would be political, to abide by DoD directives. But if there is no other motivation this would not be very honest intellectually; Ada would only be there as an excuse, since there would be no incentive to use the generated Ada code directly. Maintenance would quite naturally be be done on the original Eiffel form. This brings me to point 2 regarding preprocessors. Their disadvantages in terms of debugging, maintenance etc. are well known. I cannot speak for C++ or Objective C but in the case of Eiffel our approach is very clear: we have a full-fledged compiler, not a preprocessor. C is used as an intermediate code for the implementation, but this should be of no concern to the Eiffel programmer. Actually you don't need to know anything about C to use Eiffel. All debugging tools, all compile-time and run-time messages refer to the Eiffel source. C is used for two reasons: - For us, it's a great portability vehicle, which has allowed us to port Eiffel quickly to a large number of machines. - For users (which also includes us!), it's a cross-development facility: you can take the C code generated from Eiffel source and port it to any machine supporting C. Unless you take this compiler approach, you risk running into the problems that, as Larry recalled, plagued things like Ratfor ten years ago. Bertrand Meyer Interactive Software Engineering, Inc. 270 Storke Road Suite 7, Goleta CA 93117 bertrand@hub.ucsb.EDU
bs@alice.UUCP (01/03/88)
> If pre-processors or translators can be written for C to produce object- > oriented languages, then the same ought to be possible for Ada. Has (is) > anyone done this? What are the advantages and problems? It would be possible to extend Ada with an inheritance mechanism either in the Objective C style or the C++ style. An objective C style preprocessor would not need to know the Ada type system and would not provide integration between to ``Objective'' part and the Ada part. In fact, Brad Cox talked about ``Objective Cobol'' and ``Objective Ada'' years ago. The other alternative ``Ada++'' could be much harder work and would involve extending the Ada syntax and type system to include an inheritance mechanism in such a way that the benefits of strong typing, data hiding, and associated environment tools were not compromised. The key problem would be to achieve a proper ``seamless'' integration between Ada as it stands now and the chosen inheritance mechanisms. Naturally, the result of this process would have to look like Ada, not C++, and Ada++ would be an inappropriate name for it (unless the increment operator ++ was added in the process :-) I strongly suspect that this work would best be acomplished by extending one of the better Ada compilers to accept the new constructs. The use of a translator, that is a compiler front-end that does a complete syntax and semantic check and uses a C compiler for code generation (only), for C++ as done simply because there (to my knowledge) did not exist a C compiler with a sufficiently powerful and flexible type system to build on. These days C++ compilers that do not generate intermediate C exist. I believe that the translator approach - using C simply as assembly language - was novel at the time, but these days there exists several language implementations that takes that route to portability, including (I believe) Common Lisp and Ada implementations. > I can see at least two problems for users. Debugging of programs produced > by anything other than a compiler means your > you're looking at "ugly Ada" rather than the "super Ada" of > Objective-Ada/Ada++. This was one reason RatFor and company never caught > on widely. Exactly. Personally, I would never consider using a preprocessor based system except as a temporary and/or experimental vehicle. Extending a language using a preprocessor that knows only part of a language is inelegant and a way of asking for trouble in terms of learning, efficiency, tools, error messages, debugging, etc. > Also, standardization might suffer. I suspect, however, that the various > super-Adas would be used only in experiments, and that useful features > would eventually find their way into Ada-1993. Exactly, if you want an Ada with inheritance ready for standardization in 1993 someone must get started quite soon. Designing an inheritance mechanism that is properly integrated into the Ada type systems and reflecting the changes into the tools and libraries is going to take years. - Bjarne Stroustrup, AT&T Bell Labs, Murray Hill > Larry @ jpl-vlsi