Re: Rene is a hypocrite (OK, what else is new?)
From: Randall Hyde (randyhyde_at_earthlink.net)
Date: Sat, 14 Feb 2004 15:52:10 GMT
"luvr" <firstname.lastname@example.org> wrote in message
> "T.M. Sommers" <email@example.com> wrote in message
> > assuming that the conversion can be done automatically, there is
> > no reason to keep any intermediate format lying around.
> Oh, I can think of one simple reason: The number of "translators" or
> "convertors" will grow exponentially as the number of languages (between
> which you want to translate) grows.
Technically, they grow quadratically (i.e., O(n**2)), not exponentially.
> Think of it: If you have a system of N languages, and you add one more
> language to it, you will need to add N translators to convert from the new
> language into each of the other languages, plus N more for the conversions
> in the opposite direction.
> However, if you make use of an intermediate language, you will need just
> additional translators: One to convert from the new language to the
> intermediate format, and one to convert the other way around. Makes life a
> whole lot easier.
Though quadratic is nowhere near as bad as exponential, it's still pretty
However, I'm not 100% sure that the thought of generating the intermediate
language automatically from some other code is absolutely necessary.
Sure, it would be nice to automatically translate MASM32 includes into
the intermediate form for use by other assemblers, and it would be nice
to translate C code into the intermediate for automagically, but I see
two problems with this approach:
1. A direct translation will run afoul of copyright laws. International
agreements on the copyright law generally cover translations and it would
be pretty hard to argue that the intermediate form (and the final form)
is not a simple translation of the copyrighted work. As it is, I suspect
we'll have problems if the new works we produce contain all the symbols
found in the original work (though you cannot copyright the values
you certainly can copyright a set of symbols appearing in a document; just
you couldn't, for example, write your own novel using all the characters
in another work, such as Lord of the Rings or Star Trek).
2. Some destination languages are more semantically rich than the source
language. This means that information is lost (or never existed in the first
when going from a semantically poor language to a semantically rich
For example, C doesn't (technically) specify the size of things like ints,
and other objects. Obviously, we can make certain assumptions, but that
always safe to do. Likewise, some assemblers support text equates while
do not. Some assemblers support procedure prototypes, some do not. And so
on and so on.
For these reasons, I'd find the automatic generation of the intermediate
to be troublesome. You're going to have to manually check it out *every
you generate it*, so this pretty much defeats the purpose of automatic
A better approach might be to create a "C to intermediate format" tool to
the first pass of the file (as *most* header files we're going to want to
start off in C, anyway) and then maintain the intermediate file manually
that point forward. Maintaining only one file is a tractible problem. It's
that could easily be maintained on the net by various contributors.
all those different "language X to intermediate format" programs would be
problematic. 1. they're not easy to write; 2. they need to be maintained
with one another; 3. Once the intermediate file is generated, it's just as
maintain that file as it is any particular header file in some other
4. The temptation to use features in an assembler's header file that is
the capabilities of the intermediate format is too great ("What? Not put any
advanced HLA macros in my header files?"); 5. Once you create the
header file from your source language, there isn't much need for the
program thereafter (assuming, of course, that you maintain the intermediate
A few "language X to intermediate format" convertors would be nice. C is an
obvious example. And an "80% solution" would work fine (i.e., something that
requires a bit of manual intervention after conversion). Beyond that, I
maintaining (or generating) the intermediate files by hand is a better
creating new (and maintaining old) translator programs.