Re: Mixing Ada and C++. Is a good idea?

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Larry says

<<Although that feature of Ada 95 may be helpful, it is a shame it is
required, rather than having compilers for all languages interface
with each other automatically on a given platform.  That does require
that devotees of all languages agree that there might be a place for
other languages in the world, and so far even Ada does not have that
attribute across all its fans.
>>

First, one cannot speak for "Ada and all its fans" at any time. Given the
many ludicrous postings to CLA, one could never expect the supposed fans
of Ada to agree unanimously on anything sensible :-)

However, it clearly is the case that Ada 95 very much takes the position
that other languages have an important place. A great deal of effort went
into refining the already superior features of Ada 83 in this area. At
no time did any of those involved give any other signal than that this was
an extremely important part of the language.

So I think you can definitely say that Ada 95 and its knowledgable advocates
absolutely agree that there are places for other languages, most notably in
regard to reuse of existing libraries.

As to Larry's "shame it is required", you cannot possibly expect "automatic"
interface. In fact it is this completely ill-thought out wish that leads to
some of the weaknesses in the Ada 83 model. These are weaknesses of 
under-specification *at the language level*. The thought in Ada 83 was that
if you provide pragma Import (C, xxx), then procedure xxx will indeed
automatically interface with C on that platform.

But that is sloppy thinking. The trouble is that the parameter passing
model is different at the semantic level between C and Ada. This means
that a correspondence has to be established which involves choices that
show up at a high level of abstraction in the user code, and cannot be
buried in the code generation.

As an example, if we have a C formal parameter that is of a struct type (NOT
a pointer to struct), then how should it be modeled on the Ada side. There
are two possibilities:

As a record type
As a pointer to record type

Ada 83 had nothing to say in this area, Ada 95 chooses the pointer approach
(though this particular case is a tricky one, and the ARA agreed on the
additional pragma C_Pass_By_Copy to resolve the trickiness. The fact that
the ARA considers the specification of the mapping in this case to be of
sufficient importance to warrant inter-vendor agreement on an appropriate
pragma to resolve a remaining insufficiently specified point should of itself
be an indication of the importance attached to this issue).

Actually this seems to be the only case not 100% handled in C, Fortran,
and COBOL interface protocols in Ada 95 (and with the new pragma, which
is implemented by all Ada 95 vendors, or should be!, that little hole is
plugged).

Now C++ and Java interface issues are not yet resolved (a reflection of the
fact that C++ was not standardized, and Java did not exist, at the time of
the Ada 95 design completion), but work proceeds on to work out the best
possible common interface for Ada 95 (e.g. at Tri-Ada, Intermetrics and
Ada Core Technologies agreed to work together on trying to achieve maximum
practical commonality in interface to Java).

There simply is no such focussed concern on this issue when it comes to
other languages. If you want to level a charge against fans of a language
of ignoring other languages, that charge lies much more accurately when
applied to other languages than Ada 95!

Robert Dewar
Ada Core Technologies