SLPL(ID:3490/slp002)Simple list processing languagefor Simple List Processing Language or for Sheffield List Processing Language Atkinson, Sheffield Uni 1976 designed as an extension to Algol 60 Structures: Related languages
References: Extract: Introduction Introduction Flexibility/security trade-off SLPL was designed as an extension of ALGOL 60 concepts to provide a more versatile language to be used by undergraduates, particularly in conjunction with courses in list processing, artificial intelligence and compiling techniques. Emphasis is on ease of use and provision of good diagnostics rather than efficiency of implementation. Ease of use can be considered from two view points. A language with rigid compile time constraints reduces the possibility of run-time errors at the expense of probable compiler-time errors. This would seem to be a desirable situation. Compile-time errors are easier to locate and correct than run-time errors and several may be flagged during one compilation whereas a program will halt after a fatal run-time fault. There are applications however (e.g. see Lindsey and van der Meulen, 1971, Section 8.7.1) where a less rigid use of modes could make a program easier to write. A language with dynamic modes and run-time mode checking (e.g. POP 2- Burstall, Collins and Popplestone, 1971) provides greater flexibility and may make the construction of programs in certain application areas less cumbersome. Unfortunately this flexibility is then gained at the expense of security. With undergraduate use we have the situation that when a program 'works' for certain sets of test data that program is rarely run again. The main objective is to illustrate a particular technique (e.g. graph traversing, alpha-beta pruning, bottom-up parsing) and by writing a program a student gains a greater understanding of the technique and an appreciation of the way the technique is applied. Under such circumstances it is not so important if a program is not fully correct; the fact that it appears correct for the applications tried shows that the particular technique is understood and illustrates contexts in which it can be applied. This suggests that flexibility (and hence ease of use) might be more important than security. This, however, would be consistently true only for a programmer who never makes mistakes! Further, the degree of error checking which can be applied is proportional to the degree of security provided by the language. The security aspect must therefore be considered. It seems that some parts of a program adapt naturally to strict use of static modes (e.g. any straightforward ALGOL 60 program) whilst other parts may, as mentioned above, benefit from a more flexible approach. An underlying feature of SLPL is the combination of the security of compile-time mode compatability with the flexibility of run-time mode checking. The degree of the flexibility/security trade-off is under the control of the user. This is illustrated by the program listed in the appendix. Structured programming To encourage a structured approach to algorithmic description and program design, suitable looping and case selection facilities are included and no goto statements are allowed. An incentive is provided to adopt functional programming techniques: assignment statements and most system primitives deliver a value. This allows a saving on intermediate storage of results and more readily permits the expression of a solution as a function of an initial state (as in LISP-McCarthy, Abrahams, Edwards, Hart and Levin, 1962). e.g. (it i; read(i); print(i); i c j + i; print(i); k t- i - k; print(k)) where j and k are global integer variables can be written: print (k t print (j + print(read)) - k) and this clause delivers the value of k. The introduction of user-defined operators further facilitates this approach. Application to AI The aim of SLPL was not to provide a powerful A1 research tool but merely to present a language facilitating natural implementation of some standard A1 programming techniques. For example, topics to which the language is currently applied include general problem solving, game playing and theorem proving. A programming language applied to such fields would be cumbersome if some list processing facilities were not present. Accordingly SLPL provides Iist structures and a number of predefined operators and system primitives to process these structures. Details of the list processing facilities are presented later. Application to compiling techniques Use can be made of the list processing features of the language. Of particular benefit is the user'stack, a run-time stack accessible by the user at any point in his program. Because compiling techniques frequently utilise a stack this feature simplifies the implementation of several compiling algorithms. More important, however, than either the list processing or the user'stack is the facility to generate and execute sequences of machine code orders. Such a facility provides no obvious benefit to less specific applications and so no details are presented in this current article. It is hoped to publish details of this aspect of SLPL in a future paper (Atkinson and Duffus). in The Computer Journal 19(1) February 1976 view details in The Computer Journal 19(2) May 1976 view details in The Computer Journal 19(3) 1976 view details |