Re: Compiler vs. Translator

glen herrmannsfeldt <>
24 May 2004 00:22:07 -0400

          From comp.compilers

Related articles
Compiler vs. Translator (Paul Robinson) (2004-05-16)
Re: Compiler vs. Translator (2004-05-24)
Re: Compiler vs. Translator (glen herrmannsfeldt) (2004-05-24)
Re: Compiler vs. Translator (Richard F. Man) (2004-05-24)
Re: Compiler vs. Translator (Martin Ward) (2004-05-30)
Re: Compiler vs. Translator (glen herrmannsfeldt) (2004-05-30)
Re: Compiler vs. Translator (2004-06-06)
Re: Compiler vs. Translator (2004-06-15)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: 24 May 2004 00:22:07 -0400
Organization: Comcast Online
References: 04-05-051
Keywords: translator
Posted-Date: 24 May 2004 00:22:07 EDT

Paul Robinson wrote:

> What brought this on was that I happened to bid on a programming job
> on to write a program (in Visual Basic, of course)
> which would translate programs written in FORTRAN into Visual Basic.

Interesting idea. About 30 years ago I was working on a program to
translate HP BASIC into Fortran. I didn't actually finish it, but the
description of it was useful on the written part of my college


> I'm discovering the difference between a translator
> and a compiler and I realize just how many things you have to think
> about when you're compiling a source program, and how you have much
> more leniency when it's "just" a translator.


> 1. A translator presumes the code is correctly formatted and would
> compile if passed to a compiler. Compilers syntactically scan code to
> find syntax errors and in some cases correct them.

You could do that, but then you could for a compiler, too.
What will your translator do when given incorrect input?

In the early days of C, there was a program called lint,
separate from the compiler, which gave more detailed messages,
and checked things that compilers usually didn't.

There are some translators which are more like preprocessors which
will translate incorrect input to incorrect output. The user must
then figure out the meaning of the messages that result from compiling
the output. (Ratfor and MORTRAN are somewhat that way, both with
Fortran as the target.)

> 2. A translator produces only output for another compiler, a compiler
> (usually) generates object files and/or executables. (Some actual
> compilers generate source for another language or assembly.)

In the case where you are translating a fairly simple language into a
more powerful language, you might be able to use some of the features
on the target language to simplify the translator. Otherwise, it
probably isn't so much different.

> 3. A translator makes certain assumptions about the code being
> presented to it, that it is a complete or reasonably complete piece of
> code. A compiler will check and (usually) complain if you hand it a
> fragment of a program.

> I wrote programs in FORTRAN for over five years and I've learned more
> about the language in the last two weeks - and probably more than I ever
> wanted to know - than I learned in the entire time I spent writing
> dozens of applications using the language.

If you read comp.lang.fortran many of those details come up as people
run into them. Many of the problems of compiling Fortran are well
known by now. (If I remember right, it is almost 50 years old.)

> So I will say this: if you think you're weak in a particular
> programming language, consider writing a compiler or translator for
> it and you will realize things you had never imagined.

Just wondering, Fortran 66, 77, 90, 95, or 2003?

-- glen

Post a followup to this message

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