From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,c0f035b936128b6c X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,c0f035b936128b6c X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Ada95 to ANSI_C converter Date: 1997/04/02 Message-ID: #1/1 X-Deja-AN: 230206283 Distribution: world References: <5hbrah$ctt$1@gail.ripco.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada,comp.lang.c Date: 1997-04-02T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: > Jon S Anthony 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