Re: Compiler vs. Translator

glen herrmannsfeldt <gah@ugcs.caltech.edu>
30 May 2004 13:19:34 -0400

          From comp.compilers

Related articles
Compiler vs. Translator postmaster@paul.washington.dc.us (Paul Robinson) (2004-05-16)
Re: Compiler vs. Translator dido@imperium.ph (2004-05-24)
Re: Compiler vs. Translator gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-05-24)
Re: Compiler vs. Translator richard@imagecraft.com (Richard F. Man) (2004-05-24)
Re: Compiler vs. Translator Martin.Ward@durham.ac.uk (Martin Ward) (2004-05-30)
Re: Compiler vs. Translator gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-05-30)
Re: Compiler vs. Translator hannah@schlund.de (2004-06-06)
Re: Compiler vs. Translator jburgy@hotmail.com (2004-06-15)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 30 May 2004 13:19:34 -0400
Organization: Comcast Online
References: 04-05-051 04-05-058
Keywords: translator
Posted-Date: 30 May 2004 13:19:34 EDT

dido@imperium.ph wrote:


(snip regarding Fortran to VB translator)


> Not necessarily. In most cases, a compiler for the source language is
> not available, and it would be difficult for the translator to make such
> assumptions. I don't think it would be acceptable for the translator to
> generate incorrect code under any circumstances.


(snip)


> Unless the source and target languages are very, very similar (in which
> case a translator probably wouldn't really be worth writing most of the
> time), a translator is essentially the same as a compiler.


Well, the ones I know are called preprocessors, instead.


Consider Ratfor and MORTRAN2, both meant to improve Fortran,
and will accept many Fortran statements with little modification.


Also, many errors will go straight through to the Fortran
compiler compiling the output.


It doesn't seem that any such preprocessors (not counting
the C preprocessor) have been very popular, though.


> Run-time issues also tend to complicate matters as well, and the
> more run-time facilities the target language provides that the
> source language doesn't, the bigger the run-time library has to be.


I thought it would be the other way around. Though it isn't
so much the number of features, but the specific features
that are needed.


(snip)


-- glen


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.