CSL(ID:250/csl001)Control and Simulation Languagefor Control and Simulation Language. Esso and IBM. 1966 Language for industrial simulations. Featured a graphical reprisentation formalism from Nance and Sargent 2002: "Graphical representations were prominent in some early languages, notably the flow chart symbology in GPSS and the Activity-Cycle Diagram (ACD) (or wheel chart) in the Control and Simulation Language (CSL), popular in the United Kingdom. " People: Hardware:
Related languages
References: The first application of the language has been in the field of Monte Carlo simulation work, for which special facilities are provided. An unusual compilation approach has been followed, involving translation into FORTRAN as an intermediate stage. Extract: Introduction Introduction CSL is a programming language designed to aid in the solution of complex logical and decision-making problems. The language is experimental in type; it derives from the observation that thinking on real-life decision-making problems is based on the use of sets, and it is designed to test the applicability of this thesis. The manipulation of sets is formally described by the predicate calculus; therefore the basic approach in CSL is that of the predicate calculus. There is considerable redundancy in the facilities provided in the language; the less useful of these will be dropped in the light of practical experience rather than by arbitrary decisions in the design stage. No attempt is made in this paper to describe CSL completely as some sixty statement types are available. This experimental approach to language design has led to a corresponding approach in design of the compiler, where rapid preparation and ease of subsequent modification has been emphasized. The first part of this paper describes in more detail the basic ideas of the language. A representative selection of the available types of statement is given, and the paper concludes with some comments on the compilation approach which has been adopted. Extract: Basic ideas Basic ideas CSL (Control and Simulation Language) is designed as a tool for the formulation of complex decision making problems such as those which arise in the control of industrial and commercial undertakings. It may help in the validation of suggested control procedures by constructing Monte Carlo simulation programs to model the system under study, or be used in the implementation of such procedures in a computer-controlled system. To provide some point of contact between the discussion in this paper and the real world, we will take as an example the problem of distributing goods from a factory to various distribution points. The problem to be solved is roughly that of finding a scheduling procedure to decide which goods should be sent by which truck to which series of unloading points. In describing such a situation in a computer program, it is necessary to talk about complex objects, such as trucks and loading bays, and to describe their interactions. These objects, which we will call entities, have qualities or attributes which may for example, be described by holding numerically coded information in arrays of storage cells. Each truck is a complex object and associated with it are various attributes, such as its capacity, total mileage and average fuel consumption. This data could be stored in arrays in two ways: by associating one attribute array with each truck, or by using the truck serial number to index data arrays which hold data for the entire fleet. Traditionally the interactions of these entities have been described by the manipulation of queues. The central theme in CSL is that such queues are, in fact, ordered sets, and as such are amenable to treatment by operations on sets similar to those described by predicate logic. Scheduling decisions in the dispatching problem will involve discussion of sets of trucks, such as the set of all trucks at present in the factory, or the set of all trucks in the factory, with capacities above 3 tons and with mileage to next scheduled overhaul greater than 1,000 miles. A set is a storage device which records the names of entities. It may be used to record the names of those entities which are in a specific state or possess a specific range of qualities, and thus it provides a way of recording the attributes of entities which is a third alternative to the holding of numerically coded information in data or attribute arrays as described above. The order in which entity names are placed on a set is preserved, and so a set can be used to provide the facilities of a queue. The subgroup of entities whose names appear on a given set may be referred to intensively by use of the name of the set, rather than extensively by listing the subgroup. Computing statements can now be designed to operate in various ways on the members of a set, or to use the membership of a set to control their operation. The principal computing technique in CSL is the use of the membership of sets to control computing operations. Extract: Variable storage Variable storage CSL names are strings of letters of any length. They may not be CSL structural words. Four basic types of storage are used; cells, arrays, entities, and sets. The first three types are known as variable storage. A cell provides space for a single variable, and is addressed by a name. An array of storage locations resembles a subscripted variable as used in FORTRAN and other standard computing languages, and a specific member of the array is addressed by a subscript list thus, DATA (E, F, G) Entities of similar size and shape, and used for the same purpose. are regarded as grouped into a class and are given similar names; in the despatching problem trucks are known as TRUCK. 1, TRUCK. 2, TRUCK. P,. . . A specific truck of the class is referenced by use of a class subscript separated from the class name, as above, by a dot. This class subscript may be an integer or it may be specified indirectly by giving a cell name or using an expression in parentheses. An expression is any single-valued arithmetic expression, as in FORTRAN. If an attribute array is associated with each member of the class, then the attribute cells are referenced by a subscript list, thus TRUCK. P (E, F) The subscripts used to reference data-array or attributearray cells may be expressions. and as expressions may involve other reference to subscripted storage, this permits indirect reference or subscripting to any level. Sets are devices for recording names of entities as described above; more precisely, a set is an ordered list of class subscripts. Though a given entity may have its name recorded on many sets, any given set may only hold the names of entities of a specific class. The reason for this restriction is given in the notes on compilation, but semantic considerations cause this, in fact, to be no limitation. As an example of the three alternative ways of recording information on the qualities or attributes of entities, consider the jth attribute of the ith truck, which might be its wresent location. If each truck has associated with it a one-dimensional attribute array, then the location is expressed by a numerical code in cell TRUCK. I (J). If a one-dimensional data array named LOCATION is used to hold the locarions of all trucks, then the coded information is in cell LOCATION (I). The third way of holding the information is by the presence or absence of the name TRUCK. I on a descriptive set, such as a set called GLASGOW. As most computing statements in CSL are controlled by reference to membership of sets in general this latter alternative is preferable. Extract: Simple manipulative statements and tests Simple manipulative statements and tests The customary facilities for performing arithmetic operations on variable storage are available, and are not further described as they resemble those in FORTRAN and similar languages. Any statement may be labelled with an unsigned integer below 25,000. The simple control statement is of the form E and F are expressions, C$ is one of the six relational operators >, 2, =, f, <. < expressed in two-letter form as GT, GE, EQ, NE, LT, LE, and 1, and 1: are labels. If the result of the test is successful, control is transferred to the statement labelled 11, and if the test fails control goes to that labelled 12. A CSL program may be divided into sectors. and either or both of the destination labels may be omitted. If the success destination is not specified, the compiler assumes it to be the next statement, and an unspecified failure destination is assumed to be the first statement in the next sector. This form of destination is used in all CSL tests. It reverses the customary approach to control transfers in computing languages, in that when specific destinations are not given, transfer takes place on a test failure and not on a success. In a program which consists mainly of logical analysis this approach gives a much easier logical flow, and in most CSL programs explicit destination labels rarely need to be used. Entity names may be placed on or off sets by statements of the form ENTITY. P HEAD SETA l1 & l? ENTITY. P TAIL SETA 1, & 1: ENTITY. P FROM SETA 1, & l? These statements will add the specified entity to the set at the head or tail of the queue respectively, or will remove it from the set. Note that each of these statements implies that a test is carried out to determine whether the entity is on the set, and so a destination is given. For the first two statements, location of the entity already on the set is a failure, and for the third it is a success. Subsequent detection of the names of the entities currently at the head or tail of the queue is carried out by the FIND FIRST and FIND LAST statements which are described in a later section of the paper. The statements ZERO SETA ENTITY LOAD SETA will cause the set to be emptied or to be filled with all members of its class. The statements ENTITY. P IN SETA 11&12 ENTITY. P NOTIN SETA l1 & 12 carry out simple tests on the occupancy of sets. Repetition of a group of statements is carried out by the use of a FOR statement which can exist in two forms. The repetition instruction may be given as in a FORTRAN DO statement: FOR I = nl, n2, n3 nl, n2 and n3 may be positive integers or cell names. and I will be advanced from nl to n2 in steps of n3. The alternative form is FOR I SETA and in this case I is made equal in turn to all the class subscripts at present recorded on the set. The range of statements over which a FOR operates is given by the fact of their indentation to more places from the left-hand side of the source program than the indentation of the controlling FOR statement. Repetition statements may be nested uithin each other to any depth. DUMMY This is a dummy statement which may be used, for example, to place a statement label at the end of a FOR loop. Extract: Complex tests Complex tests The basic unit in the complex tests and compound statements is the test cliain: this is a truth functional chain of tests in what is described by logicians as disjunctive normal form; for example test l group 1 test OR test ) group 2 OR test h test ! group 3 etc. The extent of the test chain is defined by the equal indentation of all tests in the chain. omitting the OR'S from consideration in the indentation. The result of the consideration of such a cliain is a success if all the tests in one or more of the groups between successive OR'S are successful; the meaning of the above chain is (test and test) or (test) or (test and test), etc. Statements other than tests may be interspersed in a chain: they will be carried out if the previous test is encountered successfully. By this means one can set markers to indicate which path through a chain was followed during execution. An example of a complex test is the ALL tsst; ALL I SETA 1, & l2 test chain (1) This is a test to determine whether the following test chain, which contains mention of cell I, is satisfied with I such that ENTITY. I is in SETA, for all the present members of tlie set. EXISTS (E) 1 SETA 11 & l ? test chain (I) This test determines whether the test chain condition is satisfied by at least as many members of SETA as the present numerical value of (E). UNIQUE (E) I SETA l1 & l2 test chain (I) This test requires that the test cliain be satisfied for precisely as many members of the set as the present numerical value of (E). In the EXISTS and UNIQUE statements, the test chain may be omitted as the result is a meaningful test on the set population, and the expression (E) may be omitted when the value unity is assumed. Extract: Search statements Search statements There are five variants of the search or FIND statement, of which one example is FIND I SETA MAX (E) I1 & I2 test chain (I) This statement locates that member of SETA which satisfies the test chain and which maximizes the expression (E). On exit from the statement, the class subscript of the successful member is set in I. In the other variants of this statement, the criterion MAX(E) is replaced by one of the criteria MIN(E). FIRST, LAST or ANY. The test chain may be omitted in all variants, as for the EXISTS and UNIQUE complex tests. The FIRST and LAST options will select the first or last member satisfying the test chain condition, regarding the set as a queue, and the ANY option makes a random choice from the members who satisfy the condition. A destination is specified in a search statement; the fail transfer will be used if it is not possible to select a member of the set who satisfies all the conditions. Extract: Nested tests Nested tests In the description of the test chain given above, no definition was given of the type of test which may be used as a member of the chain. In fact, any test defined in CSL may be a member of any chain. including complex tests and search tests. A complex test or search test which is a member of a chain may itself involve a subchain. including other complex tests, and so on to any depth. This ability to use complex tests nested to any depth gives the language considerable analytical power and flexibility. As an example in the despatching problem, for a particular long night haul. we might wish to locate the first truck (X) in the waiting queue, of capacity 3 tons or more and with more than 1,000 miles to next overhaul, provided that we can also locate any driver (Y) who is a union member, is prepared to drive overnight and is permitted to drive trucks of the tonnage of truck (X). If a truck and driver are available, take the next statement, otherwise transfer control to the statement labelled 105. The following datement paragraph performs the entlre operation, assuming suitable storage allocations : FIND X IDLETRUCKS FIRST & 105 TRUCK. X (1) GE 3 TRUCK. X (2) GE 1,000 FIND Y IDLEDRIVERS ANY DRIVER. Y IN UNION DRIVER. Y NOTTN DAYWORKONLY DRIVER. Y(l) GE TRUCK. X ( I ) Extract: Program testing Program testing Trace statements are provided to facilitate recording of the contents of specified cells during execution. The resulting output gives the cell contents and their source language names, so that program testing can be undertaken without recourse to lower levels of language. At the time of writing an index checkmode compilation facility is being added to the compiler. In sections of program between the words START and FINISH, extra orders will be inserted to provide dynamic checks, during execution, on the contents of all index values, to ensure that any subscript value used to access any array cell or attribute is within its allowed range. In a language which permits indirect reference to any level, this facility should be available. Extract: Monte Carlo simulation facilities Monte Carlo simulation facilities The language contains several facilities, such as the provision of cells for holding time values associated with each entity. which are useful in writing simulation programs, and in providing a conceptal framework for the expression of such problems. The facilities are based on those in the General Simulation Program (Tocher and Owen, 1960) and in Montecode (Buxton and Kelley, 1962). No further description is given here as in this paper the authors wish to emphasize the nature of CSL as a general programming language. in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details in The Computer Journal 5(3) October 1962 view details CSL uses FORTRAN as an intermediate language, send in fact the flavor as well as the basic features of FORTRAN exist in CSL. The language is built around the manipulation and interrogation of "sets," a set being a list of subscripts, the subscripts indexing elements from a particular class of objects. This set handling is accomplished by some 60 statement types involving structural words such as: head, tail, in, notin,for, all, exists, find. For-loop dependence and complex tests are indicated by indental tion (an increasingly popular trend). The facilities available for chaining and nesting tests and searches should give the language considerable power and the use of indentation improves its readability, but the reviewer feels that complicated problems will still first be flow-diagrammed. As with FORTRAN, CSL suffers from a lack of available symbols and from stylized statement forms. The recursive nature of compilation used by CSL, which simplifies the making of changes and additions to the language, is important in an experimental project such as this. Similar work, culminating in the language SIMSCRIPT, has been done in this country by H. M. Markowitz, H. W. l Karr, and others. in ACM Computing Reviews 5(04) July-August 1964 view details in ACM Computing Reviews 6(06) November-December 1965 view details in ACM Computing Reviews 6(06) November-December 1965 view details External link: Online copy Abstract: This paper discusses the writing of programs to express simulation problems in the control and simulation language CSL. The descriptions in the text are in terms of a single problem, for which a full program is given as an appendix. Though some new features of the new version of CSL are described, the purpose of the paper is mainly expository. Extract: Introduction The word "simulation" is used in many contexts and has become one of the more confusing terms in the computer field. For example, it is used in the simulation of the order code of one computer on another, in the simulation of aircraft or guided weapon control systems by analogue computers, and in operational research. It is the latter use which is implied in the title and for which CSL is designed. The first version of CSL (Control and Simulation Language) was designed as a joint project by IBM United Kingdom Ltd. and Esso Petroleum Co. Ltd. (Buxton and Laski, 1962; CSL Reference Manual, 1962). Its initial applications were to the solution of problems in operational research connected with the control of industrial organizations. These problems were solved by simulation; that is, by writing in CSL a program purporting to imitate the working industrial system, and then studying the effect of changes in the methods of control of the system by manipulating the imitation program. The basic premise behind this approach is that it is cheaper and less disastrous to experiment with a computer program than to experiment with the reallife system of which that program is an imitation. Furthermore, it may be impossible to experiment on the real system if, for example, it does not yet exist. During the design period it was realized that a programming language built to imitate real-life systems on a computer is likely also to be suitable for writing computer programs to control the real system. The first major application of CSL, due mainly to Dr. J. G. Laski at Esso Petroleum Co., was in fact a program to control the distribution of petroleum products (Laski, 1965). The control program was written in CSL, tested by surrounding it with a simulation of the distribution system also written in CSL, and subsequently tested on control of the real distribution system. Of the two key words in the title "Control and Simulation Language", the first is probably the more important. This experiment, and other early uses, revealed many possible areas of improvement which led to the preparation of a second version of the language. The second version of CSL, described in this paper, has been prepared initially for the IBM 7090194 by IBM United Kingdom Ltd. The compiler has been designed and written mainly by P. Blunden, P. Grant and G. Parncutt of IBM, and the services of the author of this paper were used as consultant in the design of the language. There is little that is basically new in the work; the fundamental ideas of CSL as expressed in Buxton and Laski (1962) still stand, but the-language represents a considerable revision and extension. A full technical description is given in CSL Reference Manual (1965) available from IBM United Kingdom Ltd. Extract: Basic system description Basic system description The systems for which CSL is used have certain basic properties in common. Their components are described in terms of groups of objects known, for lack of a better word, as classes of entities. All entities in a class are similar in that their basic properties are similar though not necessarily identical. The properties of entities may require quantitative storage or qualitative storage, and the logical interactions between entities may be extremely complex. in The Computer Journal 9(2) August 1966 view details C.S.L. had been published (Buxton et al., 1962) and available for two years before Courtaulds decided to redevelop it for their own computers (Courtaulds Ltd., 1964). Up to that time, C.S.L. had only been available on a service bureau basis and was rather expensive to run; Courtaulds started this work because they were anxious to have a complete range of software available at their own installation. These realizations of C.S.L. were not, like the first, prompted by a particular urgent project so that we could afford to sit back and carefully study the methods to be adopted and the language used. Considerable care was taken to extend the source language to attempt to overcome the limitations of C.S.L. discovered by previous users. This paper will concentrate on these extensions and the compiling methods used, since the original language has already been published in this journal (Buxton et al., 1962). The paper describes two projects simultaneously-the provision of compilers for the Honeywell 400 and the Honeywell 200 series (the latter being sponsored by Honeywell Controls Limited). Each compiler was written and tested by one man working for one year. Many of the extensions which E.C.S.L. allows are catered for, in rather different ways, in C.S.L. 2 (Buxton, 1966) which was produced by IBM during the same period. C.S.L. was originally compiled into FORTRAN. This was clearly undesirable in this case because the performance of the FORTRAN compilers for these computers was not known at the time. Secondly, many of the limitations on C.S.L. were necessary only because of the restrictions on FORTRAN. But by far the most important reason was the need for an improved and efficient communication between the computer system and the programmer. In particular we wished to make it easy for the programmer to proceed successfully without any knowledge of other, more basic, programming languages. in The Computer Journal 9(3) 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 The Computer Journal 9(3) 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 in SIGPLAN Notices 13(11) Nov 1978 view details BISRA were the pioneers of digital computing in the steel industry, taking delivery of a Ferranti Pegasus in 1956. Since many problems in the steel industry were amenable to examination by simulation, BISRA developed Montecode, based on Pegasus Autocode, for the purpose. Montecode enabled simulation models to be easily developed, though running times could be long. Collcutt described several early applications of Montecode. United Steel received their Pegasus in February 1958 and quickly concluded that the use of machine code and Pegasus Autocode for simulation were too cumbersome. They decided to develop a general simulation language (GSL) for Pegasus. Progress was described by Tocher and Owen in a paper to the second IFORS Conference in 1960. Experience indicated that a substantial saving of time in writing and testing computer simulations was achieved with GSL on a modified Pegasus, with no severe loss of running speed compared to Pegasus Autocode. It was also flexible enough to deal with a wide range of problems. The use of GSL and Montecode did not spread much beyond the steel industry as they were machine-dependent, though some of their designers assisted in the development of machine-independent simulation languages such as CSL. By 1960 IBM's dominance of large computers was beginning, and FORTRAN was becoming established as a standard scientific programming language. (ALGOL 60, a powerful and versatile machine-independent language, never really got off the ground except in academic circles, partly because IBM refused to accept it.) The use of FORTRAN for simulation was described by Barnett," also at the second IFORS Conference. He used an IBM 704 with various 'adjuncts', including a cathode-ray screen (to show graphs, contour plots etc.), switches and a flexiwriter to key in data and decisions. Perhaps this was the first use of visual interactive simulation. Barnett made the point, which is sometimes forgotten, that developing a logical understanding of the process is more time-consuming than the coding! In 1965 Collcutt confirmed the trend towards the use of Fortran (and languages based on Fortran such as CSL) for carrying out machine-independent simulations. He commented that for simple problems Montecode proved adequate, but for complex problems an even higher-level modular language was needed. One further pioneering development at United Steel was the simulation of information flows and the use of operational gaming so as to improve the real-time control of (stochastic) steel-making plant. Initially management games, involving real managers, were designed so as to validate the simulations, but the potential for improving control and evaluating information quality was soon realized! Amiry and Mellor and Tocher describe a simulation model of a plant which has a model of the information system superimposed upon it, incorporating information lags sampled from distributions. A production game was then played, where the actual management controlled the model of the plant using information displayed on a mimic display board of events and forecasts of events. The speed of information transmission could be successively increased, and the achieved improvements in control evaluated to determine an economic balance, i.e. how much improvement in information quality is worth paying for and how it is best used. in SIGPLAN Notices 13(11) Nov 1978 view details ECSL, developed for Courtaulds Ltd. by the originators of CSL, became a popular language in the UK. ECSL departed from the heavy emphasis on FORTRAN of CSL, and Clementson (1966, p. 215) with the expressed intent to embrace users who were non-programmers relied heavily on the entity-cycle diagrams for model input. ECSL was the target language for CAPS (Computer Aided Programming System), the first interactive program generator (Mathewson 1975). in The 27th Winter Simulation Conference 3-6 December 1995 Hyatt Regency Crystal City, Arlington, VA view details |