Related articles |
---|
Automatic Language Conversion vbdis@aol.com (2002-05-23) |
From: | vbdis@aol.com (VBDis) |
Newsgroups: | comp.compilers |
Date: | 23 May 2002 01:32:11 -0400 |
Organization: | AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com |
Keywords: | translator |
Posted-Date: | 23 May 2002 01:32:11 EDT |
For several purposes I want to use multiple front-end and back-end
processors for source code. The front-ends read textual source code or
binary code (libraries...), and create an tree for that
information. Then dedicated back-end processors shall output that tree
in various programming languages, as far as possible.
Now I have a problem with the intermediate tree structure, because
every language has unique features, which can not always be
represented in other languages. Consider the Basic OnError handling,
which has no counterpart in other languages. This means that the
information in the tree possibly must be extended for every new input
language, in structure or attributes. That's not a problem for itself,
but how to track these updates in the back-ends, so that it's possible
to know where the modules must be updated? When new features result in
additional information in commonly used node classes, how can the
back-end processors (and their programmers) know about that new
information?
I'm looking for any hints about useful node and tree structures, which
are extensible without complete redesigns, and how to organize the
implementation of the tree walkers for output generation.
DoDi
[This is awfully close to the UNCOL problem, a universal intermediate
language, which is one of the great black holes of computing research,
with failed projects dating back to the 1950s. Once you get beyond
toy examples, there's so many special cases that it becomes hopelessly
unwieldy. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.