Gargoyle(ID:198/gar003)the name has no particular significance except that it was "intended to be humorous" Algol derived language for compiler writing. Machine specific for rapid execution. Work borne of a dissatisfaction with other systems. People: References: A Gargoyle program consists of a set of global data-declarations and a series of "routines". The routines may contain local data-declarations but will contain "instructions". An instruction has five addresses of which the programmer is only aware of four, the fifth being inserted by the Gargoyle compiler. (A Gargoyle compiler is compiled by a Gargoyle compiler, the first being produced either by magic or written in some other language.) The four addresses are called else, conditional action (action for short), "next" and "link". The principle of the work of an instruction is as follows. The piece of the program (in its ordinary sense) starting at address action is entered. This piece will in general evaluate a Boolean variable. If it is false a steering program is entered at a label FALSE. If the Boolean variable is true, the following program is performed and exit is made to a label TRUE in the steering program. The addresses else, next and link either point to another instruction or else they can have one of the "values" exit or error (the latter is left blank in manuscripts). At the label FALSE, if else is not exit or error the instruction in else is obeyed next. At the label TRUE, if next is not exit or error, else is first observed. If it is different from error a new level of operations is begun, moving all local variables one step down. This is to allow backtracking. If the link is different from error, a new level is again started because we now enter a "subroutine" which requires its own space. Finally control goes to next. The fifth address tells how many locations in the stack must be reserved for local variables, etc., in the next level. When else or next is exit, backtracking takes place and control goes to the stored link in the previous level. If this link also was exit, the process continues. If else, next or the stored link was error, backtracking one level again takes place and the stored else value in the previous level takes control. This scheme obviously permits unlimited and recursive subroutine formation. In addition to the global and local variables there exists a third type of variable, the status variables. They indicate the position of pointers in the input or output strings, etc., and will vary from application to application. The status variables can usually be packed into two computer words and this is assumed in the sequel. The status variables are also stored in the stack and when a new deeper level is entered they are brought forward. When backtracking takes place there is a difference bweteen error-backtracking and exit-backtracking. In the former case nothing is done to the status variables; the new level contains the correct status variables. In the latter case,however, the status variables must be brought back to replace the old ones. in [ACM] CACM 7(01) (Jan 1964). view details The GARGOYLE language appears to consist of ALGOL type statements which are sequenced by a "steering program." Increased compiling speed is achieved by reducing interpretation to a minumum, which means "visiting" the steering program the smallest number of times (only in those cases where recursive ability is required). The compilation of an ALGOL assignment statement is presented as an example, but no information is given the reader relative to any actual compilers produced by this method. The author omits references with the rationale "this is a scientific paper and not a who's who in compiler writing." in ACM Computing Reviews 5(05) September-October 1964 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 Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details |