Related articles |
---|
source-to-source translators, what language for unparsers cfc@shell01.TheWorld.com (Chris F Clark) (2009-05-05) |
Re: source-to-source translators, what language for unparsers sh006d3592@blueyonder.co.uk (Stephen Horne) (2009-05-06) |
Re: source-to-source translators, what language for unparsers rtrnews@googlemail.com (2009-05-06) |
Re: source-to-source translators, what language for unparsers idbaxter@semdesigns.com (Ira Baxter) (2009-05-06) |
Re: source-to-source translators, what language for unparsers Ruslan@Shevchenko.Kiev.UA (rssh) (2009-05-08) |
Re: source-to-source translators, what language for unparsers bear@sonic.net (Ray Dillinger) (2009-05-09) |
Re: source-to-source translators, what language for unparsers gopi.onthemove@gmail.com (2009-06-03) |
From: | Ray Dillinger <bear@sonic.net> |
Newsgroups: | comp.compilers |
Date: | Sat, 09 May 2009 02:30:35 -0700 |
Organization: | Organized? Seems unlikely. |
References: | 09-05-026 |
Keywords: | translator |
Posted-Date: | 09 May 2009 18:54:43 EDT |
Chris F Clark wrote:
> There are probably other formalizations. For example, I recall that
> sorcerer was a tree-walker associated with ANTLR designed for
> source-to-source transformations. Perhaps, there is something in Eli,
> Cocktail, the Russian Armory tools, or Coco that I would be advised to
> copy.
There are cases where the source semantics aren't even available
in the target language.
I recently read about the effort to port ROGUE (the game program
by Wichman and Toy, originally written around 1980 at Berkeley).
The original program reserved space in one of the executable
modules for the high-score list; the executable would modify
its own disk image whenever the high-scores changed.
As a result of a buggy implementation of these semantics, the
order in which the object files were linked was critical, and
failure to link in the correct order would result in relocation
of the reserved area within the program image, so on achieving
a high-score you'd wind up modifying some code that actually
got called, much later, in someone else's game, resulting in
very peculiar and mysterious behavior - sometimes a crash.
Issues of buggy implementation aside, the semantics of a reserved
modifiable data area within an executable file, and of an
executable modifying its own on-disk image, are not available
in most languages. If you imagine "translating" such a thing
into, say, Java or Haskell, it will make me giggle. When you
port a program that does something like that into a language in
which things like that cannot be done, you are not translating;
you have to create an alternative mechanism (in this case a
separate highscores file) that serves the same purpose by very
different means.
On the other hand, if you *don't* ignore the issues of buggy
implementation, can you imagine a translator that would faithfully
reproduce the exact same buggy behavior which was, in the original,
an artifact of an unintended interaction with the linking process?
After all, it is only our human expectations that declare this to
be an "error"....
Bear
Return to the
comp.compilers page.
Search the
comp.compilers archives again.