Xref: utzoo comp.compilers:1300 comp.lang.misc:5483 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!ico!haddock!ima!esegue!compilers-sender From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.compilers,comp.lang.misc Subject: Re: Multi-compilers Summary: Why not have a general language? Keywords: design, source Message-ID: <2576@l.cc.purdue.edu> Date: 18 Sep 90 14:29:25 GMT References: <9009110403.AA03158@csd4.csd.uwm.edu> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: cik@l.cc.purdue.edu (Herman Rubin) Followup-To: comp.lang.misc Organization: Purdue University Statistics Department Lines: 78 Approved: compilers@esegue.segue.boston.ma.us 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) -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.