Re: Ada95 to ANSI_C converter

[jsa@alexandria (Jon S Anthony)]

In article <E7xots.51o@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Jon S Anthony <jsa@alexandria> wrote:
> >Hmmm, _fundamentally_ inefficient?  I'm not confinced.  Of course, it
> >definitely will be completely unreadable.
> 
> Robert is probably alluding to the fact that C doesn't catch overflows.
> Of course, one could imagine a translator that assumed the Ada program
> isn't bothered by overflows...

OK, that makes sense.


> I believe ICC used various implementation-dependent tricks to catch
> overflows efficiently.  And they didn't claim to produce readable C --
> just correct C.

So, were these tricks still captured in generated C or were they
something else?  If they were still captured in the generated C, then
it would seem that the use of the term "fundamentally" here is not
quite accurate.  I mean, the ICC work would be an existence proof to
the contrary.


> >Perhaps.  But that is irrelevant.  The specific case is whether
> >Jennifer wants this approach, and it's unclear why people should
> >presume what it is she really wants and then trash her for it.
> 
> Indeed.  IMHO, the correct response to the common "does there exist a
> translator from language X to language Y?" question should be some
> questions: Do you want any or all of (1) completely correct
> implementation of language X?, (2) Do you want the generated code to be
> fast?, and (3) Do you want it to be readable to regular language-Y
> folks?  Perhaps also, (4) do you want the typical language-Y debugger to
> make sense of it?

Excellent points.  This really makes sense to me.


> I have witnessed successful semi-automated translations from one
> language to another, even when readability was important.  IMHO, it
> helps if (1) the translator can take advantage of the idioms used by a
> particular program in the source language (e.g. we don't care about
> overflow, or we don't use nested procedures), (2) the source language is
> higher level than the target, (3) one is willing to fiddle with the
> source code, to make the target code come out reasonable, and (4) one is
> willing to fiddle with the target code, after having gotten it to
> "work".

Agree on all points.  One example of this (all points 1-4) that I know
of concerned translating Lisp to C - where the intent was readable
result.  The old Chestnut translator for this (particularly if you
were willing to go with 3) IMO produced truely great results.  In
general I would say the generated C was far better than most hand
crafted C I have seen.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com