Re: Algol 60 Syntax

"Steve Ross" <>
15 Jan 2000 14:36:26 -0500

          From comp.compilers

Related articles
Algol 60 Syntax (2000-01-12)
Re: Algol 60 Syntax (Andreas von Gorup) (2000-01-15)
Re: Algol 60 Syntax (2000-01-15)
Re: Algol 60 Syntax (Munk, ir. H.) (2000-01-15)
Re: Algol 60 Syntax (2000-01-15)
Re: Algol 60 Syntax (2000-01-15)
Re: Algol 60 Syntax (Steve Ross) (2000-01-15)
Re: Algol 60 Syntax (2000-01-15)
Re: Algol 60 Syntax (2000-01-15)
Re: Algol 60 Syntax (ma haibing) (2000-01-15)
Re: Algol 60 Syntax (2000-01-19)
Re: Algol 60 Syntax (William B. Clodius) (2000-01-21)
| List of all articles for this month |

From: "Steve Ross" <>
Newsgroups: comp.compilers
Date: 15 Jan 2000 14:36:26 -0500
Organization: Compilers Central
References: 00-01-037
Keywords: parse, UNCOL, comment


I can't help with the Algol-60 syntax, but the work you're doing
sounds interesting and quite similar to something I'm looking at. I
have a COBOL parser (obviously your favourite language ;-) ) built
using established tools and am looking at more flexible alternatives,
e.g. a configuration file driven approach similar to the one you

I wanted to sound a note of caution on the universal language
transformation theme, though. The problem with transforming between
two languages A and B via some interim representation R (Forth,
byte-code, etc.) is that the interim form ends up as a sort of least
common denominator. Each semantic unit of A (a data definition, a
statement) maps onto one or more semantic units in R. This transform
is easy.

However, it takes one or more units of R to map to a unit of B.
What's more, the patterns of units of R generated from A will in
general not be the patterns that produce meaningful semantic units in
B. At best, you would end up with unnatural-looking code in language
B that looked like it had been written by someone who knew languages A
and R, but who didn't know B.

That's not to say that language transformation is a useless goal, but
that it should always be a human-driven process, with the
transformation tool as an aid, and never a fully-automated process.
Other inputs, such as a model of the application architecture, can
help produce a meaningful transformation.

Steve Ross
RMC Ltd.
[The original universal intermediate language project in the 1950s was
called UNCOL. It failed, as has every subsequent attempt, most
recently ANDF. The reason is exactly that the semantics of both
programming languages and machine architectures are hard to specify,
and extremely variable in small but crucial ways, so any universal
intermediate suffers heat death from special cases as it's generalized
to more than a few source and target languages. I find it very
frustrating that a new UNCOL project shows up every few years by
people who seem utterly unwilling to believe that the people who tried
UNCOLS and failed before weren't stupid, and wave off the fundamental
issues until they fail in exactly the predictable way. -John]

Post a followup to this message

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