Re: Translator design decisions

The UNCOL problem is actually quite simple. It's not the foundations
are insecute, but our ability to build subtly different structures on
top of the foundation so easily that is the cause. A perfect example
is printing. Find two languages that have exactly the same printing
operations with the same semantics. We can't even get operating
systems to agree on how to terminate lines in text files.


And therein lies the rub. All those seemingly trivial differences can
easily be represented in an assembly language program, but determining
which of those differences is relevant to any given program requires
solving something equivalent to the halting problem. So, as one
builds an UNCOL, one has to capture all the differences down to the
most minute level.


        As an aside, there are two ways to attempt that: either the union
        or intersection approach. In the union approach one keeps adding
        new operators for each new conceptual combination, and the number
        of operators grows without bound due to the combinatorial
        explosion of choices that can be combine. In the intersection
        approach, one keeps attempting to find a finer grain of atomic
        principles out of which everything can be constructed, and one
        fails due to the unbounded combinations reducing the intersections
        to essential infinitesimals.


In any case, when one attempts to build an UNCOL, one ends up building
a massive bloatware structure, where there are hundreds of unused
combinations that have to be represented, analyzed, and dealt with.
None of these combinations are used in any one language, but they are
the cross-products of features from different languages that have to
exist in a unified solution, because if the cross-product doesn't
work, then at some point a language will be added to the set that will
depend upon that cross-product and it won't work.


This is not the problem in the single language case, because one
simply never considers the combinations that can never occur. One may
not even be aware that some of the combinations exist, because they
are impossible due to some other characteristic of the language. This
is wonderful and allows us to deal with simple things simply. When
one starts buiding an UNCOL, one slowly expands that set, slowly
making things more and more complex as new interactions that were
previously impossible become evident. When you've added enough
combinations, one simply cannot understand all the potential
interactions and things become unmaintainable, because when fixing one
thing, one somehow forgets some other cross-product that needs a
slightly different interpretation and one then breaks that.


It's like the diagonalization argument for proving one set is larger
than another. There exsits some language that you will need to
represent in your UNCOL whose semantics at each point is distinct from
each language previously enumerated in your UNCOL. Thus, there is the
UNCOL writers' full-employment theorem.


Hope this helps,
-Chris


******************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)

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