johnl@ima.UUCP (04/14/87)
[This exchange of messages started when Charles asked if there was a
standard way to translate his source programs when he changed the syntax
of his language a little. Both the language and the programs are invented
for educational purposes. I opined that such a translator is unlikely
to be much easier than any other compiler. -John]
If there isn't such a thing as an easy translator (since there is
no such thing as an easy parser), how about an easy to use translator
generator? Obviously, for almost all translations, the complete specification
of the language, in BNF or CFG or such, would need to be available and the
specific translation would be initmately related to the specification of the
language. The concepts and routines used in editor generators would be
applicable.
I honestly don't know if it is fruitful. I am sure that some have
done some work on it and I would like to know the results. Even using
the tools avaiable here (YACC/lex :-( ). It is still better than writing
translators by hand.
Charles Merriam, Computer Scientist in Training
merriam@hub.umb.edu, or merriam%hub.umb.edu@csnet-relay
[My response.]
I guess I don't think there is a lot of difference between a translator and
any other kind of compiler. The lexical and syntactic analysis are the same
either way, except that in a compiler you usually throw away things like
comments and white space and in a translator you probably want to pass
them through, usually with a hack like hanging a comment onto the
preceding token.
Once you've done that, generating "object code" in C or Pascal is not that
different from generating it in assember. You can usually get by without a
synbol table, but I never found that maintaining the symbol table was all
that hard.
I suppose you could take a very different approach and use something like
Snobol4, and have a bunch of patterns and matching translations that you
apply to the entire body of the program.
I'll post these to mod.compilers to see if anybody has other ideas.
John
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestjohnl@ima.UUCP (04/16/87)
In-Reply-To: <541@ima.UUCP> >I guess I don't think there is a lot of difference between a translator and >any other kind of compiler.... There is a long and honorable history of source-to-source translators. In the old days they were called SIFT programs. I forget why. The bottom line is that it is easy to do the easy stuff and impossible to do the hard stuff. If you push, you end up translating a reasonable program in the source language into a mess in the target language. Even if it works you don't want it. An example of pushing: Fortran: DIM X(20,30) X(1,2) = 7 C: double x[20*30]; x[(1-1)*20+(2-1)] = 7; It is sometimes less ugly if you are taking a simple language into a more powerful one since you can pick a subset of the target language which is close to the source language. It is also not too bad if you are willing to use obvious (but wrong) equivalents. For example, translate to C: double x[21][31]; x[1,2] = 7; above and then hand-repair any faults this introduces because of the difference in array layouts and Fortran single subscript "cheating". For similar languages (say C and Pascal), the easy part can usually be done by building the parse tree for the source program, transforming it into the parse tree for the target program, and then printing the leaves on a left-to-right sweep. It is also sometimes useful to first simplify the source language before attempting to translate. The original IBM PL/1 level F compiler beat all the complex constructs into simple constructs before starting compilation. The same trick helps in source-to-source. For example: C before: y = ++x; C after: x = x+1; y = x; Pascal after: x := x+1; y := x; There is a school of thought that says using SIFT tools is harmful -- It is better to take the opportunity to seriously re-engineer and rewrite old code. Management can often be sold on a rewrite if the alternative is tool building. It is a cost/benefit decision, where effort involved and the quality of the product have to be taken into account. /s/ Bill W. M. McKeeman mckeeman@WangInst Wang Institute decvax!wanginst!mckeeman Tyngsboro MA 01879 [Oh yeah, SIFT, the SHARE Internal Fortran Translator, translated one dialect of IBM Fortran to another. And almost 20 years ago I tried a Fortran->PL/I converter from IBM and, true to form, it produced the most astoundingly awful PL/I program, due mostly to subtle differences in the way that Fortran and PL/I output formatting, which look almost the same, are defined. -John] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
johnl@ima.UUCP (04/18/87)
I have put together a skeleton of a source to source translator for
XPL/S to C. It turned out I did not need to build a tree. Simple
statement to statement code generation did the trick. Unfortunately
the need for the translator went away so I never got much beyond
parsing the XPL and a brief design of the runtime string handling
system (the unique part of XPL).
Anyone willing to pay for the uucp transfer is welcome to it...
//Z\\
Jim Ziobro
rocksanne!z
ziobro.henr@xerox.com
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-request