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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a7cfec93e22adfc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-04 06:57:25 PST From: "Ira D. Baxter" Newsgroups: comp.lang.ada References: <3c81060d$1@giga.realtime.net> <5ee5b646.0203021621.ce5a579@posting.google.com> Subject: Re: ada to C++ translation Date: Mon, 4 Mar 2002 09:06:35 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 NNTP-Posting-Host: t1-30.realtime.net Message-ID: <3c838b53@giga.realtime.net> X-Trace: giga.realtime.net 1015253843 t1-30.realtime.net (4 Mar 2002 08:57:23 -0600) Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news-x2.support.nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newsfeed1.cidera.com!Cidera!giga.realtime.net Xref: archiver1.google.com comp.lang.ada:20766 Date: 2002-03-04T09:06:35-06:00 List-Id: "Robert Dewar" wrote in message news:<5ee5b646.0203021621.ce5a579@posting.google.com>... > "Ira D. Baxter" wrote in message news:<3c81060d$1@giga.realtime.net>... > > > And we have a nice start; our tools already can process > > Ada9 and C++, > (I assume that Ada9 is a misprint) [Yes, fumble fingers happen, sorry.] > But that's relatively straightforward. After all anyone > can process Ada 95 using ASIS, > and it is not clear what "processing C++" > means if you are generating C++ as the output. If you have a code generator that directly produces fragments of C++ text, then "processing C++" is uninteresting. It also makes composing generated fragments difficult, because the composition has to be pure macro-like substitution or text concatenation. This kind of approach can produce C Front like code, but it is likely to be inefficient and hard to maintain. Our tools manipulate trees, which allows them to compose fragments and then carry out optimizations on the result, because the tool understands the structure (and to the extent one is willing to invest effort) the semantics of such structure. "Processing C++" means that our tools can parse/compose/transform/prettyprint C++ code. > > so the real task is to define the map between them. > > That indeed is the (very difficult for Ada to C++) part. > A translation from Jovial to C is by comparison entirely > trivial, since the languages are both low level languages > with no major semantic problems in the translation that > I can see. Language translations are almost never trivial. JOVIAL has all kinds of nasty stuff. Data overlays. Packed fields. Macros. Exceptions(!). > > How such things are defined are usually defined by > > customer dictate > > That's a very tall order for Ada to C++. For example, > in the case of object oriented stuff, the correspondences > are far from trivial, the same is true for generics and > templates. I'll agree, that the Ada to C++ translation is probably harder. [Now that I understand that Averstar claims to have such a tool, I offer them as an existence proof]. [The point I had intended to make is that customers often have lots of secondary issues about execution environments, libraries, etc. that they want taken into account for such a translation. This adds to the scale of the translator engineering.] > Going back to the tool environment, it seems clear that > starting with ASIS is the best here, although your tools > may "process" Ada 95, it is very unlikely that they > generate the full semantic information available from ASIS > and for sure it seems like you need this full information > for an automatic translation to C++. ASIS certainly has a leg up in have the full semantic analysis of Ada available to it. We presently don't go so far with *Ada*. We do go that far with C and Java, so it isn't a tool limitation, it is an engineering investment problem. And yes, this is a significant investment, and would probably count for half the effort in a translator. OTOH, being able to "process" the resulting code (by composition, optimization, etc.) is key, we think, to produce a translated result that appears clean. ASIS offers nothing here. One could argue this, too, is just an engineering problem. The difference is that DMS was designed as infrastructure for this overall task. I don't believe ASIS was. This is not to denigrate ASIS; if you want analysis in the Ada world, it looks like a very good tool. If you want more, it might not be the right tool. > What is certain is that, even with this starting point, > this translation is a major project. Agreed. > What is not certain is that it is a practical project. > Of course one can translate Ada to C, just as one can > translate C++ to C (that is after all what C front does), This is pure code generation. Smart folk don't look at the result, they just compile and run it. > but most usually people who ask a question about Ada to > C++ translation have legacy Ada code that they want to > magically translate into high level maintainable C++. Agreed. > I am dubious that this is possible at all, and even more > dubious that it ever makes sense to attempt it. We think if it is practical to produce such code, our tools are well positioned to do this. [And if Averstar already does this well, the point is probably moot]. YMMV. I'll be the *last* person to push somebody into such a conversion. If there's a more economical (or more business-sensible) approach that leaves them in Ada, that's the way they should go. If such a conversion starts and the value isn't really clear, it'll get killed in mid project and that wastes everybody's time, including ours. And I'll even agree that many starry-eyed desires for conversions are probably not sensible. That doesn't mean that conversions are always inappropriate. Rightly or wrongly, people perceive that engineers with good Ada skills are hard (and getting harder) to find, that tool vendor support is fading, that end-customer acceptance is weakening for those reasons. Personally, I think this is a shame. I'm actually a closet Ada fan; it appears to have one of the most rational designs of any of the languages I've seen, and systems built in it appear to generally have better quality. (One might argue this is caused by filtering out people who won't read the LRM). But I'm not the marketplace, and it doesn't always do what we personally think is technically rational. If you remember BetaMax VCRs, they were technically better than VHS. But the only VCR survivors made the arguably rational business decision to go with VHS. This is not a recommendation on my part to switch to C++. It is merely an observation that some businesses likely will. Ira D. Baxter, Ph.D. CTO Semantic Designs 512-250-1018 http://www.semdesigns.com