UNCOL(ID:143/unc001)
Proposed universal intermediate language
UNiversal Computer Oriented Language.
A universal intermediate language, much discussed but never implemented.
Most of the justifications for JAVA, with the nice comment:
"This concept is not particularly new or original. It has been discussed by many independent persons as long ago as 1954. It might not be difficult to prove that this was well-known to Babbage, so no effort has been made to give credit to the originator, if indeed there was a unique originator"
Interestingly the Orchard-Hays paper suggests that it is the wrong way to go, for reasons that are similarily contemperaneous
Related languages
| Gorn experimental compiler | => | UNCOL | Influence | |
| UNICODE | => | UNCOL | Influence | |
| UNCOL | => | ACT | Reaction to | |
| UNCOL | => | ANDF | Influence | |
| UNCOL | => | BASE | Implementation of | |
| UNCOL | => | HPCode-Plus | Influence | |
| UNCOL | => | Janus | Implementation | |
| UNCOL | => | Metcalfe syntax language | compiler for | |
| UNCOL | => | Wegstein algebraic language | Antipathy to |
References:
in [ACM] CACM 1(10) (Oct 1958) view details
SOLUTION--THE THREE-LEVEL CONCEPT ("UNCOL").
A. History. This concept is not particularly new or original. It has been discussed by many independent persons as long ago as 1954. It might not be difficult to prove that "this was well-known to Babbage," so no effort has been made to give credit to the originator, if indeed there was a unique originator.
B. Outline. The system is composed of three levels of language [...]
1. ML Level. The lowest level (closest to the bits in the machine hardware) is composed of all the current or future ML's.
2. POL Level. The highest level (furthest from the machine) is composed of all the current and future POL's.
3. UNCOL Level. The center level is a single language "UNCOL," the Universal Computer Oriented Language.
4. Generators. Generators are those routines which perform the transformation from the POL's to UNCOL. They are analogous to present generative compilers except that they produce, not a number of ML's, but only UNCOL. As with present compilers, one of these would be needed for each POL used with a given machine.
5. Translators. These are routines which perform the transformation from UNCOL to ML, and are like present compilers in that they are one-time preprocessors before execution of the customer's program. However, they are not so complex nor so difficult to write as the "generators" described above, since UNCOL, being computer oriented, has many things in common with each of the ML's. For each machine only one translator need ever be produced, regardless of the number of POL's formulated or used.
in [ACM] CACM 1(08) (Aug 1958) view details
in [ACM] CACM 1(08) (Aug 1958) view details
Included in the English version of the book is the result of an experiment with a translation program run on an IBM 704 at the Paris office of IBM France on June 19, 1959. The program used was that of Mr. A. F. R. Brown of Georgetown University. The text is a foreword to the book, the wording of which does not show any preediting. The translation program was designed for the translation of texts in chemistry and nuclear energy. About half of the book consists of an historic exposition of the subject, and many references are given. The rest of the book deals with the details of various methods used in automatic translation and specific syntactical and lexical problems. The exposition is not too mathematical for the linguist, or for that matter anyone interested in language.
To the reviewer, it was of particular interest to find that the problems which arise in natural languages have a very close resemblance to those in procedure languages. The UNCOL concept (called INTERLANGUAGE) as well as the METALANGUAGE concept can be found here. Those familiar with the construction of processors will find discussion of familiar ideas (the pre-scan which removes implied meaning and replaces it by explicit syntactic operators, macro expansion, and the assembly process) which are all implied in the translation of natural languages. It is, however, clear from the discussion in the book that an interplay between the people involved fin processor construction and those in translator construction has not as yet taken place. The book could without any doubt give the necessary understanding to both groups and make possible significant advances in Techniques.
Although the author is director of the ATALA Association, little stress is placed on his own accomplishments tend the work done in France. Typical of his exposition is the following quote: "To Booth and Richens, to Reifier and the M.I.T. team, to Panov and his colleagues, must go the main credit for clearing the ground and laying the solid foundations upon which it is now possible to build." The book will certainly be a valuable and welcome addition to the library of those concerned with machine translation of natural languages and also it will provide the newcomer with all of the necessary background material in order to carry on new investigations which will without any doubt offer many challenges and rewards.
in ACM Computing Reviews 2(05) September-October 1961 view details
in [JCC 17] Proceedings of the 1960 Western Joint Computer Conference, May 1960 view details
in Datamation 6(01) January 1960 view details
each combination of new POL's and new machines. With UNCOL, however, each new machine produced will only require a single translator (presumably in addition to whatever executive and service routines may be necessary) to convert UNCOL to the new machine language, and each new POL will only require a single translator to convert the problem language to UNCOL. It is pointed out that a universal problem language is unlikely, for human beings engaged in data processing have demonstrated historically an inability to reach agreement on a problem language. Furthermore, universality may not even be desirable for it implies agreement which implies compromise. This may lead to a system adequate for most problems but satisfactory for none. (Such being the case, one questions the likelihood of ever achieving a UNCOL.)
in ACM Computing Reviews 2(03) May-June 1961 view details
in [ACM] CACM 4(03) (March 1961) view details
in [ACM] CACM 4(03) (March 1961) view details
in [ACM] CACM 4(01) (Jan 1961) view details
in Goodman, Richard (ed) "Annual Review in Automatic Programming" (2) 1961 Pergamon Press, Oxford view details
in [JCC 19] Proceedings of the Western Joint Computer Conference, May 1961 view details
in ACM Computing Reviews 2(05) September-October 1961 view details
This language -- although its goals are laudable and a useful life of only one decade is sought -- seems doomed to be a victim of two trends. First, compilers (problem-oriented languages) are not as difficult to write as they once seemed to be. In fact, it may be simpler to produce machine code than UNCOL. Second, the increasing diversity of computers places a self-defeating burden on a computer-oriented language. The necessity of dealing with relatively small subsets of the language greatly diminishes the universality.
in ACM Computing Reviews 3(04) July-August 1962 view details
in The Computer Journal 4(4) January 1962 view details
Finally, there is "UNCOL: the myth and the fact," by T. B. Steel, Jr. UNCOL stands for Universal Computer Oriented Language, which might be described as electronic Esperanto. Its purpose is as an intermediate stage between problem oriented language and machine code, so that translation always goes in two stages, first to UNCOL, then to a particular machine code. The paper argues the advantages of this technique, and is mainly devoted to a highly abstract discussion of the problems involved in the translations. The basic assumption is that it is necessary for every machine to accept every language, so that if there are M languages and N machines, the use of UNCOL reduces the number of translators required from M x N to M ? N. At the end of the paper the author mentions an alternative solution, the compiler-compiler, or AUNT (Automatic Universal Translator), which he dismisses because "nobody knows how to do it." One must assume that he is not aware of the work of Brooker and Morris.
in The Computer Bulletin June 1962 view details
in The Computer Bulletin June 1962 view details
The author recognizes that one of the difficulties faced by the UNCOL concept is the fact that algorithms expressed in virtually all existing source languages are in fact not completely machine independent, and points out that for UNCOL to be successful it must have the ability to separate the machine-dependent aspects of the program from the machine-independent aspects.
The author discusses an alternative concept to UNCOL involving the use of metalanguages to describe source and target languages, but makes no mention of the syntax approach [ Brooker and Morris. "An Assembly Program for a Phrase Structure Language." Computer J. 3 (Oct. 1960), 168- 174; Irons, E. T. "A Syntax Directed Compiler for ALGOL 60." Comm. ACM 4 (Jan. 1961), 51-55].
The topics discussed in this paper are of considerable interest in that they identify the problem areas and difficulties that face workers in the field of compiler automation.
in ACM Computing Reviews 4(01) January-February, 1963 view details
in Steel, T. B. Jr. (ed.): Formal lanquage descripttion languages for computer programming. Amsterdam: North Holland 1966 view details
Other TWSs
ETC (Garwick [Gar 64], Gilbert [Gil 66] and Pratt [Pra 65])
In this section we describe three other efforts, that are best described as syntax-directed symbol processors. For various reasons, these systems have not had the impact of those discussed above and are presented in less detail.
The GARGOYLE system [Gar 64] was developed for the Control Data 3600 by Jan Garwick at the Norwegian Defense Establishment. There are reasonably complete descriptions in internal reports, but the published paper [Gar 64], which was written first, gives only a vague picture of GARGOYLE.
GARGOYLE is like TMG (Section III.A.1) in many ways; the recognizer is top-down with a facility for directing the search. All syntactic and semantic statements are written in a five-entry tabular form: (label) (else} (next} (link} (action). The sequencing rules are quite complex (partly because backup is handled implicitly) and are normally done by a "steering routine." The backup mechanism also requires complicated data handling involving stacking of some variables and copying of others. All five entries are used in multiple ways; e.g. the label may instead be a code controlling how the line is to be interpreted.
The following example would be used to process an (assignment statement).
(label) (else) (next} (link) (action}
R ASSIGN
L VAR
0 VARIABLE 1
1 NEXT 2 if S YMB=:COLEQ then
VARy----WORD
2 3 ASSIGN 4
3 EXPR 4
4 RETURN OUTTEXT ("STO", 10);
OUTFIELD (VAR, 20) ;
The first line is the header for routine ASSIGN, whose local variable, VAR, is declared in the second line. If VARIABLE finds a (variable} then the next symbol must be COLEQ (":=") or the routine fails. Line 2 is a recursive call of ASSIGN for treating multiple left sides; the first backup will lead to EXPR (which will compile the right side), and subsequent returns will execute statement 4 once for each variable in the multiple assignment. The (action} in statement 4 produces text for storing into each successive value of VAR.
The language of the (action} column includes partial word operators and a few fixed routines for table searching, input-output, etc. The GARGOYLE user is expected to embed assembly statements frequently, and the entire (action} language appears similar to the high level machine language of [Wir 66a]. GARGOYLE has been used by its author to help implement a complex language [Gar 66], but its wider use will require a somewhat cleaner design and considerably better publication.
Thc TWS of Gilbert and McLellan [Gil 67] is based on some syntactic ideas of Gilbert (Section II.C, [Gil 66]) and an attempt to revive the UNeOL [Ste 61] concept. Source programs are to be translated into a machineindependent language, BASE, which in turn can be translated into many machine languages. The first translation is described in an intermediate language which is a macro assembly language having a few fixed data structure conventions; the second translation is described in a string form like that of TMG. Although there are a number of good ideas in the paper, they are not significantly different from others in this section. Some of the bad ideas, however, are uniquely illustrative.
The UNCOL notion of a machine-oriented but machineindependent language has always foundered on the diversity of languages and computers. Gilbert and McLellan attempt to avoid this by Mlowing new operators to be defined in BASE and passed blindly to each BASE-to-machinelanguage translator. This gives the appearance of machineindependence but leaves untouched the basic problem of which macros to choose. The authors also make a point of the fact that their system is "rigorously based." This presumably encouraged them to use the set of strings "AmB-AmB-CCC '' as the programming language example illustrating all aspects of their system. Finally, in a classic example of misplaced rigor, they exclude infinite loops from their system by not permitting loops and go to statements.
The only reference in this paper [Gil 67] to other TWS literature is [Ir 61].
The AMOS system developed by Pratt and Lindsay [Pra 65, Pra 66] is a direct application of list-processing ideas to TWSs. The source language is translated into an intermediate language (I-language) which is interpreted by AMOS. The I-language is a simple list processing language with some string processing operations and crude arithmetic; e.g. "*ADD* P1, P2, P3" means "add P1 to P2 and put the result in P3." The I-language was designed to be minimal and to be expanded in macro fashion. The syntax is treated by a variant of production language (Section II.B.5) relying heavily on recursive calls; the semantics is written in I-language. The most interesting feature of AMOS is the attempt to provide for the translation of data structures as well as programs. AMOS has had some minor successes in handling list structures, but the problem deserves much more attention (ef. Section IV.C).
in [ACM] CACM 11(02) (February 1968) view details
in [ACM] CACM 11(02) (February 1968) view details
in [ACM] CACM 15(06) (June 1972) view details
in Computers & Automation 21(6B), 30 Aug 1972 view details