Re: C to ADA translators.

[howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken.llnl. gov!taurus.cs.nps.navy.mil!shimeall@gatech.edu (timothy shimeall)]

In article <C52rx3.B67@crdnns.crd.ge.com> groleau@e7sa.crd.ge.com (Wes Groleau 
X7574) writes:
>1. I found some free code in C that meets 95% of my requirements.  I want
>to translate to Ada so that I have some hope of meeting the other 5% by my
>deadline.  (I was able to make a nice low bid because I knew about this code.)

You miss the point of the objection.  
First, you are assuming that a mechanical translation from C to Ada
would produce a reliable program written in Ada from a reliable
program written in C.   This is debatable, given the ambiguity
of several of the common idioms used in C code.
For example, it is quite possible that the correct
interpretation of the c declaration:
   void dosomething(a)
   int ***a;
would be the Ada declaration:
   procedure dosomething(a:in out int_ptr_array) is ...
(in other words, the first * in the C declaration indicates an
 in out parameter, the second * indicates the parameter is an
  array, and the third * indicates the array holds pointers.)
but how would you design a software system to disambiguate this
from the OTHER possible interpretations of int ***a?

To get around this (and many other, similar) problem, you need a 
complete review of the generated Ada code by someone who thoroughly 
understands the C code being translated, the rules used to translate it, and
the proper Ada translations -- I submit (from experience in trying
mechanical translations) that this review will be more expensive,
and slower, than reverse-engineering the "free code" and rewriting it from
scratch.

Second, you assume that your customer wanted the code in Ada because
of some mystical belief in Ada.  This is probably false.  He wanted it
in Ada because he didn't want to have to support multiple language
compilers and multiple language training for the duration of the
system lifespan.  In short -- He wanted the system in Ada to simplify
maintenance.  A mechanically-translated piece of software is likely to
be unmaintainable, unless you do a LOT of reworking and commentary. So
you deliver an unmaintainable system and your company loses reputation.

>2. My (non-programmer) systems engineers (in our company, those are the guys
>that write the specs and can't distinguish between requirements and 
>implementation) want me to incorporate the 16-Kilbyte FORTRAN simulation they
>used to develop the spec into the test support software.  Management is not
>sympathetic to my desire to re-design something that "already works"

Point out to the systems engineers that you cannot guarantee that the
mechanically-translated simulation will produce the results the FORTRAN
simulation produced, whereas a redesigned simulation might (if done 
properly) be so guaranteed.  If they want you to incorporate the unverified
simulation anyway, go ahead and do it, but ask for the instruction in
writing... 

If you want to go with some sort of translation, look into DRACO or
similar efforts that abstract the DESIGN from an implementation in 
the source language and then refine the design into the target
language.  But be warned, such tools are a) difficult to find and
b) require effort to use.
				Tim
P.S. Note, while I'm writing from a Navy cite, I'm not a spokesperson
for the Navy, nor should any of the above statements be considered 
policy statements of any organization.