Re: Translator design decisions

On Jan 21, 3:00 pm, Chris F Clark <c...@shell01.TheWorld.com> wrote:
> Our estemed and wise moderator wrote:
>
> > Just to save you time, the so-far inevitable trajectory of an UNCOL
> > project is that they try a couple of semantically similar source
> > languages, and a couple of semantially similar targets, it seems to
> > work OK, and wild enthusiasm ensues. Then as they add more sources
> > and more targets, it becomes apparent that each one requires a bunch
> > of new special case hacks in the intermediate language, which rapidly
> > overwhelms whatever common stuff they thought they had. After a
> > while, the project quietly disappears. Heard from ANDF lately?
>
> I've worked on several semi-successful UNCOL projects, ...
> There is a lot of compiler infrastructure to leverage, which is what
> promotes the initial success and wild enthusiasm.
>
> However, in the end, there is a huge body of implicit assumptions
> present in any given language that pervades the semantics and that is
> what eventually kills the commonality, because if one ignores the
> hidden semantics the tool seriously fails to capture some important
> detail, which either results in incorrect behaviour (if one choose
> something overly unsafe) or abysmal performance (if one choose
> something overly pessimistic).


We build one of the sets of "compiler infrastucture to leverage"
(DMS). We get a lot of the "so you can you build universal
translators?" question, However, we don't believe in the UNCOL
reasons, which I think the moderator and others in this thread have
nicely spelled out. So we end up telling people the inconvenient
truth, which many find to be a bummer as it violates their fantasy.
Yet one more example of "no magic here".


What we do believe is that you can build families of similar
translators. In some sense, the idea is to run up to the edge of
chaos and not jump in (e.g., Chris's "semi-successful"). The art is
in knowing how not to go to far. I won't claim we are lots better at
that art than anybody else :-{ But we have built single-front end,
multiple back end translators for domain specific langauges (abstract
factory controls to factory controller languages). We have built
language-dialect-capable front end, target-language with variant
dialects translators (notably several varieties of JOVIAL in, varities
of C out). But typically when we are faced with a translation
project, we try to build a specific translator for that (actually, for
a specific combination of input technologies [language, screen
management, databases,...] to avoid getting swamped in the
generalities problem.


What you *can* do is to really leverage the common infrastructure.
Generic parsers, attribute grammars, symbol tables, transformation
machinery, all these mechanisms work just fine for translation tasks,
especially when they are integrated cleanly from the start.


So we think while you may not be able to solve the UNCOL problem, you
may be able to solve the infrastructure problem. It is rather like
having the OS services provided for general applications.


Having the OS doesn't solve the problem of writing application
software. But you'd be considered insane if you proposed to write
some standard application software without using an OS.


You'd be just as crazy to try such applications using just a
scheduler, or just a file system, or just a printer driver because you
get that part somewhere. Yet many naive attempts are made to build
complex program analysis or transformation tools using just YACC, or
some set of unintegrated tools.


I find it astonishing how many people don't seem to understand this
analog in the custom software tools arena.


Ira D. Baxter, CTO
www.semanticdesigns.com


[Yes, this agrees with my experience. The reason the UNCOL myth is so
seductive is because you can indeed build tools and you can build
working translators that target a narrow set of similar front or back
ends. (Particularly these days when so many of them are eight bit
byte addressable with power of two word size.) The trick is to drive
up to the edge of the cliff minus a foot or two. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.