CLP(ID:384/clp001)Cornell List ProcessorCornell List Processor. List processing language, an extension of CORC, used for simulation. Places Structures: Related languages
References: Presented in this paper are the highlights of CLP, a teaching language which has been employed at Cornell University and was constucted to serve as a means of introducing simulation and other list-processing concepts. The various advantages of CLP are discussed and examples are given. List processing is a convenient mode of description for many of the more interesting and provocative areas of computer application, but the available languages--such as IPL-V, COMIT, LISP, SIMSCRIPT--require a level of programmer sophistication that makes them ahnost prohibitive for normal classroom use. CLP was constructed to see if some of the power of the list-processing concept could not be made available in a language that requires no more than a "FORTRAN level" of sophistication. CLP was superimposed upon a locally developed language called CORC. This is a general algebraic language, now taught to all engineering undergraduates at Cornell and many students in other colleges of the University. It is a simple source language, implemented by compilers (Control Data 1604 and Burroughs 220) that attempt much more than the usual level of error detection and error correction. The result has been a considerable reduction in the average number of machine approaches required to achieve successful execution, as compared to previous experience with BALGOL and FORTRAN. Through batch processing with a special operating system there has been a considerable reduction in the machine time required for compilation and execution as compared to FORTRAN. After introductory experience with CORC some students find it necessary, and not difficult to progress to FORTRAN for major computational projects. The intent of CLP was to provide a comparable path of graduation for students who were interested in essentially non-nmnerieal computation. CORC is entirely included in CLP; the CLP compiler for the 1604 will process CoRc programs without modification. The basic CORC statements are given below. In CLP a number of additions were included that have nothing to do with list processing but which relax some of the inflexibility of basic CoRe. These include access to magnetic tape auxiliary storage, a "computed GO TO" statement, compound statements (in the ALGOL sense), and a very flexible Report Generator to specify variable output format, patterned after the generator of the SIMSCRIPT language [2]. In some cases CLP is used simply for the benefit of one of these extentions. The real purpose of the language, however, is served by the introduction of a new kind of data element, and an additional set of statements for their processing. In addition to the usual variables, vectors and matrices, the programmer can declare, by name, his intention to use a particular kind of "entity" in the program. An "entity" is a particular kind of data record, as defined in the declaration, such that (a) the number of a given kind of entity of interest will vary from time to time during execution, and (b) the set of entities may be dynamically partitioned into various different subsets, called lists. Extract: Example - Car For example, for a program intended to simulate detailed vehicular flow in a certain street network one might declare an entity named CAR. A CAR would be described by a number of "attributes," such as possibly SPEED, DIRECTION, LENGTH, ACCELERATION, POSITION, and each CAR would be represented by a record containing a data word for a value for each attribute. In effect, the attributes are simply variables with the entities providing an unusual manner of subscripting. The progrmnmer writes DIRECTION OF CAR(I) to identify one particular value out of the many DIRECTION variables that may exist at the moment. The entire phrase DIRECTION OF CAR(I) is used exactly as a normal algebraic variable in any of the regular CoRe statements as well as the added CLP statements. During the course of computation entities may either enter or depart from the sphere of interest. The programmer uses the statements LET I = NEW CAR and ERASE CAR(J) to accomplish this. The former creates a new entity CAR in the sense that a block of the required size is removed from available storage, assigned to be a CAR, and the variable I receives the value of an identification number for this CAR. ERASE CAR(J) simply releases the record previously assigned to CAR(J) for reassignment. The whole point of this dynamic assigmnent of storage is that the total number of cars which might be considered at some time during the execution of the program is potentially beyond the storage limits of the computer, and this scheme allows the records for new arrivals to overlay the records for cars which are no longer of interest. This can of course be accomplished by programming in a general algebraic language, but it is convenient to have it done automatically by the compiler. It is also convenient to be able to associate groups of CARs by their position, their drivers' intentions, their velocity, or any other characteristic that might be of interest or use to the processing routines of the program. These groupings are called lists and during the course of execution entities may be placed on lists by the statements: INSERT CAR(I) FIRST ON LANE(K) INSERT CAR(G q- 2) AFTER CAR(P) ON INTERSECTION( NORTH) INSERT CAR(M) BEFORE CAR(N) ON PARKROW(S) INSERT CAR(H) LAST ON REPAIR A particular entity can, of course, be on several different lists at the same time. (Actually the list consists of a set of names of entities, rather than the entities themselves, and these names can be used as often as required.) If desired, the arrangement on a list can be in order of the value of a particular attribute of the entities on the list. For example, a list called LANE might be declared to consist of CARs ranked by the value of the CAR's attribute POSITION. A CAR would be placed on the list during execution by the statement: INSERT CAR(I) RANKED ON LANE Similarly entities can be removed from lists as their status changes during execution: REMOVE CAR(I) FROM LANE Ordinarily this statement is preceded by another that determines the identification number of the entity to be removed: LET I = CAR FIRST ON LANE REMOVE CAR(I) FROM LANE LET X = CAR LAST ON LANE REMOVE CAR(X) FROM LANE LET X = CAR BEFORE CAR(Q) ON LANE REMOVE CAR(X) FROM LANE LET DELETE = CAR AFTER CAR(HALT) ON LANE REMOVE CAR(DELETE) FROM LANE One can index the execution of the CORC REPEAT statement over all of the entities that exist at the moment of encounter: REPEAT ADVANCE FOR ALL CAR(I) (where I is then the indexing variable in the program block labeled ADVANCE) or over all of the entities that are on a particular list: REPEAT PARK FOR ALL CAR(X3) ON WAIT Extract: CLP and the CORC philosophy The CLP compiler continues the CORC philosophy of providing extensive error detection, attempts at error correction, and a guarantee of reaching execution regardless of the state of the program. All of the Conc monitoring is present, as well as additional tests appropriate for the additional statements and data elements of CLP. CLP's debt to SIMSCRIPT is obvious and is readily acknowledged. In fact, the decision to define and implement CLP grew out of a semester's experience in teaching SIMSCRIPT in a graduate course in simulation. So much time was spent on instruction in the language that other material was neglected. In comparison CLP will not accommodate as large a problem as SIMSCRIPT for although the memory of the 1604 is as large as the 7090-94 it is not used as efficiently (no partial-word packing) and the compiler remains in core during execution. (This is not logically necessary, but it was convenient and expedites batch processing of student programs. The available space for obiect program has always been sufficient.) Execution is somewhat faster, and compilation is much faster than SIMSCRIPT. Although the programmer must construct his own timing routine for a simulation, and occasional circumlocutions are necessary as compared to SIMSCmPT'S flexible and powerful statements, in general CLP is a much easier language to use. However, CLP was intended for a very specific purpose and not as a general alternative to SIMSCRIPT. As a vehicle to introduce the concepts of simulation and list processing, and as a means of implementing the relatively small problems that are characteristic of student investigations it has been most successful. It has been used rather extensively in the last year at Cornell and the results have been very encore-aging. Students have been able to write programs for sinmlations, adaptive and heuristic gameplaying routines and other pseudointellectual processes as regular course assignments that would previously have been considered to be of scope appropriate for a thesis. in [ACM] CACM 8(04) April 1965 view details INSERT CAR(I) FIRST ON LANE(K) INSERT CAR(M) BEFORE CAR(N) ON PARKROW(S) etc. This is not a general type programming language, but one intended for a specific purpose - - in which area it would certainly seem to be useful. in ACM Computing Reviews 6(05) September-October 1965 view details in [ACM] CACM 9(10) October 1966 view details in [ACM] CACM 9(10) October 1966 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in [ACM] CACM 9(10) October 1966 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 |