From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 7 Apr 93 19:24:07 GMT From: agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!darwin.sura.net!sg iblab!a2i!dhesi@ucbvax.Berkeley.EDU (Rahul Dhesi) Subject: Re: C to ADA translators. Message-ID: List-Id: 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 also: dhesi@cirrus.com