* Re: Ada++ & Objective-Ada
1988-01-01 3:12 Ada++ & Objective-Ada larry
@ 1988-01-02 1:11 ` Bertrand Meyer
1988-01-03 1:00 ` bs
1 sibling, 0 replies; 3+ messages in thread
From: Bertrand Meyer @ 1988-01-02 1:11 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Ada++ & Objective-Ada
1988-01-01 3:12 Ada++ & Objective-Ada larry
1988-01-02 1:11 ` Bertrand Meyer
@ 1988-01-03 1:00 ` bs
1 sibling, 0 replies; 3+ messages in thread
From: bs @ 1988-01-03 1:00 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread