Re: C to ADA translators.

[agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!darwin.sura.net!sg iblab!a2i!dhesi@ucbvax.Berkeley.EDU (Rahul Dhesi)]

In <66126@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

>fine, but before you mechanically try to translate the software to Ada,
>why not try to build an Ada binding to the C or FORTRAN code,
>(.i.e. RTFM about pragma interface and friends)

Once again, let me gently point out that those of us used to BSD
environments do things much more simply when we need to make major
applications communicate with one another.  We invoke each as a separate
process, and we let them communicate via messages (usually through
'pipes', often through intermediate files when the communication is
batch-oriented).

For a small and clean example of this, look at the 'cterm' package
written in C, which allows any program written using perl to uses
screen management routines.  The perl process communicates with the
cterm process via a bidrectional pipe.

Monolithicity for the sake of monolithicity, i.e., assuming that the
only way of combining two software modules is to link them together and
make one big mass out of them, is a bad idea.  Although it's true that
Ada was primarily designed for embedded systems, my guess is 95% of the
Ada code out there implements conventional applications that the rest
of us happily write in C, Fortran, or Cobol, without having any special
requirements to interface with specific hardware.  It's such
applications that are best implemented as relatively self-contained
modules each running as a separate process in the BSD style.  Given
such a paradigm, there is no need to convert existing C code into Ada,
or even link it with an Ada program.  Just give it a convenient
interface and let it run as a separate process.
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com