Related articles |
---|
Algol 60 Syntax dsutton@acumen1.com (2000-01-12) |
Re: Algol 60 Syntax gorup@altavista.net (Andreas von Gorup) (2000-01-15) |
Re: Algol 60 Syntax wb@yorikke.arb-phys.uni-dortmund.de (2000-01-15) |
Re: Algol 60 Syntax harm.munk@philips.com (Munk, ir. H.) (2000-01-15) |
Re: Algol 60 Syntax dvdeug@x8b4e53cd.dhcp.okstate.edu (2000-01-15) |
Re: Algol 60 Syntax wclodius@aol.com (2000-01-15) |
Re: Algol 60 Syntax steve.ross@rmc-ltd.com (Steve Ross) (2000-01-15) |
Re: Algol 60 Syntax Martin.Ward@smltd.com (2000-01-15) |
Re: Algol 60 Syntax dsutton@acumen1.com (2000-01-15) |
Re: Algol 60 Syntax mah@colorado.edu (ma haibing) (2000-01-15) |
Re: Algol 60 Syntax dsutton@acumen1.com (2000-01-19) |
Re: Algol 60 Syntax wclodius@lanl.gov (William B. Clodius) (2000-01-21) |
From: | "Steve Ross" <steve.ross@rmc-ltd.com> |
Newsgroups: | comp.compilers |
Date: | 15 Jan 2000 14:36:26 -0500 |
Organization: | Compilers Central |
References: | 00-01-037 |
Keywords: | parse, UNCOL, comment |
Dan,
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
mentioned.
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]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.