Re: Rene is a hypocrite (OK, what else is new?)
From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 02/14/04
- Next message: luvr: "Re: tiresome ranting"
- Previous message: Ed Beroset: "Re: Development tools......"
- In reply to: luvr: "Re: Rene is a hypocrite (OK, what else is new?)"
- Next in thread: luvr: "Re: Rene is a hypocrite (OK, what else is new?)"
- Reply: luvr: "Re: Rene is a hypocrite (OK, what else is new?)"
- Reply: Frank Kotler: "Canonical format for header files (was... who cares?)"
- Reply: T.M. Sommers: "Canonical format (was Re: Rene is a hypocrite (OK, what else is new?))"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 14 Feb 2004 15:52:10 GMT
"luvr" <spam-loving-criminal@spam-sink.net> wrote in message
news:402e11a4$0$309$ba620e4c@news.skynet.be...
>
> "T.M. Sommers" <tms2@mail.ptd.net> wrote in message
> news:K2udnbK3FO6PJrDdUSdV9g@ptd.net...
>
> > 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.
See, N*N.
>
> However, if you make use of an intermediate language, you will need just
two
> 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.
Amen.
Though quadratic is nowhere near as bad as exponential, it's still pretty
bad.
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
themselves,
you certainly can copyright a set of symbols appearing in a document; just
as
you couldn't, for example, write your own novel using all the characters
developed
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
place)
when going from a semantically poor language to a semantically rich
language.
For example, C doesn't (technically) specify the size of things like ints,
unsigneds,
and other objects. Obviously, we can make certain assumptions, but that
isn't
always safe to do. Likewise, some assemblers support text equates while
others
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
format
to be troublesome. You're going to have to manually check it out *every
time
you generate it*, so this pretty much defeats the purpose of automatic
generation.
A better approach might be to create a "C to intermediate format" tool to
generate
the first pass of the file (as *most* header files we're going to want to
create
start off in C, anyway) and then maintain the intermediate file manually
from
that point forward. Maintaining only one file is a tractible problem. It's
something
that could easily be maintained on the net by various contributors.
Maintaining
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
*in sync*
with one another; 3. Once the intermediate file is generated, it's just as
easy to
maintain that file as it is any particular header file in some other
assembler;
4. The temptation to use features in an assembler's header file that is
beyond
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
intermediate
header file from your source language, there isn't much need for the
translator
program thereafter (assuming, of course, that you maintain the intermediate
file).
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
think that
maintaining (or generating) the intermediate files by hand is a better
solution than
creating new (and maintaining old) translator programs.
Cheers,
Randy Hyde
- Next message: luvr: "Re: tiresome ranting"
- Previous message: Ed Beroset: "Re: Development tools......"
- In reply to: luvr: "Re: Rene is a hypocrite (OK, what else is new?)"
- Next in thread: luvr: "Re: Rene is a hypocrite (OK, what else is new?)"
- Reply: luvr: "Re: Rene is a hypocrite (OK, what else is new?)"
- Reply: Frank Kotler: "Canonical format for header files (was... who cares?)"
- Reply: T.M. Sommers: "Canonical format (was Re: Rene is a hypocrite (OK, what else is new?))"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
