comp.lang.ada
 help / color / mirror / Atom feed
From: bertrand@hub.ucsb.edu (Bertrand Meyer)
Subject: Re: Ada++ & Objective-Ada
Date: 2 Jan 88 01:11:02 GMT	[thread overview]
Message-ID: <260@hub.ucsb.edu> (raw)
In-Reply-To: 871231191213.05i@VLSI.JPL.NASA.GOV


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

  reply	other threads:[~1988-01-02  1:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1988-01-01  3:12 Ada++ & Objective-Ada larry
1988-01-02  1:11 ` Bertrand Meyer [this message]
1988-01-03  1:00 ` bs
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox