Re: Multi-compilers

In article <9009110403.AA03158@csd4.csd.uwm.edu>, markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
>
> Recently, an interesting idea has come to mind for a new kind of compiler:
>a Multi-Compiler. What makes it different from your typical compiler is that
>it accepts code from more than one source language: many source languages in
>fact.
>
> However, it's an idea that is easier said than conceived. What would it
>look like? The whole issue seems to revolve around this concept (which I
>borrow from linguistics) of 'code-switching'.
>
> Code-switching is where a multi-lingual speaker switches from one language
>to another, often in mid-sentence. For instance, while waiting for a
>departure from an airport in Budapest, I got in a conversation with an East
>German traveller. However, my German was weak, his English was non-existant,
>and our Hungarian was not very strong. So we found it necessary to literally
>sprinkle our conversations with almost random switching between German and
>Hungarian. Each language offered something which compensated for something
>lacking in (our knowledge of) the other.


But you were not using specialized languages. Any one of the languages would
have been quite adequate for the task. It was knowledge in one language which
compensated for lack of knowledge of the other. If the two of you both knew
Swahili, you would undoubtedly have used that for conversation. This is not
the problem in computer languages.


> A good programmer will also face the same kind of dilemma. Different
>languages are designed to do different things better. An extreme example is
>the case of writing a truly practical AI control program which would ideally
>handle all the intelligent rule-based tasks in Prolog, and all the
>event-driven tasks in assembly and C, and maybe even the recognition and
>learning tasks in the assembly of a special purpose neural net chip.


I disagree. Apart from machine language, there is no language designed to
use the power of the computer. Mathematicians, physicists, chemists, etc.,
have specialized vocabularies added to their "normal" languages, and would
not think of writing an article exclusively in their jargon. Also, they
have had to interact with other jargons, and there is no attempt to preclude
constructs, as the present computer languages do.


Even Basic English, an attempt to produce an easily learned limited version
of English, was not really that limited. The main limitation was to replace
verbs and tenses by compound expressions using participles and auxiliaries.
But nothing was really left out. Algol failed in its goal as an algorithmic
language by omitting even well-known algorithmic ideas, the most notable being
the existence of a list of outputs from a replacement statement. This has
been discussed somewhat; a list is not a struct, or a class in an object-
oriented language, but a temporary labeling.


We really need the approach taken by the users of natural language, namely,
if it isn't there, put it in! If it is clumsy, do it differently, although
this can be very hard to achieve. Why can we not have an overloaded, weakly
typed, "natural" notation assembler, with a macro processor which can expand
things in the user's fashion?


> The question, naturally, is: when are you allowed to code-switch?
>Depending on how you answer this, you either got a closely integrated set of
>*distinct* compilers (like the Quick series marketed by MicroSoft), or a
>truly integrated programmer's utility.


Only the latter will do. Having part of the program produced by one
language and part by another requires combining them by someone knowing
the syntaxes of both, and even the machine representations of both. In
some cases, this can be done by a super-linker, but not by a linker. But
does the super-linker even have the information? We would have to augment
the symbol table by having the parameter structure for each call listed,
and also for each return. The code would likely be clumsy and slow.


The language can be produced, and presumably compilers can be written.
But it must take the approach that everything is possible, and that
utility is more important than esthetics.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
--

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