ALP(ID:156/alp001)Autocode List-Processing Languagefor Autocode List-Processor List-processing extension of Mercury Autocode. from Cooper 1962 "The scheme is designed in the form of eleven instructions added to the existing Autocode Language (Brooker, 1958) so that Autocode instructions may be intermingled with these new symbol-manipulating instructions. Only a desirable minimum of new instructions is included, but subroutines to perform more complicated list manoeuvres, such as copying tree structures or joining lists, may easily be built up from these. As one of the authors (D. C. C.) has already produced an IPL interpreter for Mercury it is probable that the language is biased in this direction rather than in the direction of other symbol-manipulation languages." Hardware:
Structures: Related languages
References: Extract: Introduction 1. Introduction The purpose of this paper is to describe an addition to the Mercury Autocode Language so that it may deal with problems requiring list-processing techniques as used in such languages as IPL (Newell and Tonge, 1960) and LISP (McCarthy, 1960; Woodward and Jenkins, 1961). The number of extra Autocode instructions has been kept to a minimum (11) so that this extension is very easily learnt and forms an easy introduction to this technique. The scheme to be described has been implemented on Mercury as an addition to the Autocode, but at present it operates only on cells in the fast store of Mercury and there is thus a restriction to a total of about 500 cells. This of course precludes the use of the scheme in most problems in which it might be useful, but in later machines, such as Atlas or Orion, this scheme could form a powerful addition to the Autocode. The scheme is designed in the form of eleven instructions added to the existing Autocode Language (Brooker, 1958) so that Autocode instructions may be intermingled with these new symbol-manipulating instructions. Only a desirable minimum of new instructions is included, but subroutines to perform more complicated list manoeuvres, such as copying tree structures or joining lists, may easily be built up from these. As one of the authors (D. C. C.) has already produced an IPL interpreter for Mercury it is probable that the language is biased in this direction rather than in the direction of other symbol-manipulation languages. Even with the storage limitations of Mercury, it has been possible to write a program to perform analytic differentiation of algebraic expressions written in a generalized form of the Mercury Autocode Language. The ALP system has also proved useful in the writing of a statistical survey program. This involved the programming of a simple compiler for which the user defines in a simple verbal language the information on punched cards and the questions he wishes to ask. It is assumed in the following paragraphs that the reader is familiar with the broad outline of the Mercury Autocode Language. Extract: Cells, Symbols and Links 2. Cells, Symbols and Links The storage available in the computer is divided up into cells which consist of two parts, a symbol and a link (a cell will usually occupy one word in the computer). Symbols are the fundamental units which are manipulated by the language. A number of symbols may be joined together to form a list, and the symbols on these lists may be manipulated by means of the new instructions provided. Thus we can find whether a given symbol is on a list; and then we could delete this symbol from the list or perhaps add another symbol either before it or after it. The interpretation of the symbol is left entirely to the programmer (there is no internal marking as to whether a symbol is local or regional, as there is in IPL). A symbol in ALP consists of a number of fields each of which is capable of holding the address of any cell. However, any other desired meaning may be attached to the symbol. In any particular implementation of the language there will be a maximum number of fields allowed. It is not necessary to use all the fields and it is possible to refer to any one or more of the fields separately. (The present version of ALP, written to operate in the fast store of Mercury, allows up to three fields of ten bits each.) The link of a cell is the address of the next cell on the list. If the cell referred to is the last cell on a list its link is made 0 (zero) to signify this. A link of 1 is used for a special purpose. in The Computer Journal 5(1) April 1962 view details It is-pointed out that Mercury's storage limitations impose severe restrictions on the use of ALr, "but in later machines, such as Atlas or Orion, this scheme could form a powerful addition to the Autocode." in ACM Computing Reviews 3(06) November-December 1962 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 |