LPL(ID:4298/)

List processing language 


for List Processing Language

Extension of PL/I to enable the control of lists, this was creation to permit the operation of FOL, the File Operations Language


Related languages
APL-PL/I => LPL   Influence
PL/I => LPL   Extension of
SLIP => LPL   Influence
LPL => FOL   Compiled by

References:
  • Claybrook, Billy G. "FOL: A Language for Implementing File Organizations for Information Storage and Retrieval Systems" view details Extract: The LPL Language
    The LPL Language
    Most of the statement forms in LPL are similar to those in FOL so in order to conserve space we give only a brief description of the LPL DEFINE statement, data types, and attributes.

    LPL Data Types and Attributes
    The language includes the data types REAL, INTEGER, ALPHA (equivalent to PL/I CHARACTER), POINTER, LIST, STACK, and QUEUE. LPL has attributes NODETYPE, IDENT, and RFCNT. The declaration
    DCL ITYP INTEGER NODETYPE, ID INTEGER IDENT, RC INTEGER RFCNT;
    declares ITYP to be an INTEGER variable representing the type of a node, ID to be an INTEGER variable having the identification attribute (i.e. ID represents an ID field like that in a SLIP node), and RC to be an INTEGER variable having the reference count attribute. The meaning of these attributes will be described further in the discussion of the DEFINE statement.

    Definition of a Node
    The DEFINE statement in LPL allows the user to describe the nodes that he desires for an application. Each time the DEFINE statement is executed it sets up a template describing that node type. Suppose that we have the declaration statement :
    DCL ITYP INTEGER NODETYPE, RV REAL
    IV INTEGER, CV ALPHA(20), LK POINTER,
    ID INTEGER IDENT, RC INTEGER RFCNT;
    The mode of the variables in this declaration statement indicate to the DEFINE statement the attributes of the fields to be included in a node. The format of the DEFINE statement is illustrated in the example:
    DEFINE NODE(ITYP, RV(1), IV(J), CV(K), ID(L), RC(M), LK(N));

    The variables in the argument list must appear in a declaration statement preceding the DEFINE statement. The I, J, K, L, M, and N INTEGER quantities (they could be INTEGER constants) indicate how many entries of each data type are in a node. Each node can have four types of values: REAL, INTEGER, ALPHA, and POINTER. The IDENT and RFCNT entries in a node allow the user to have his own identifier and reference count fields. This increases the flexibility of LPL by allowing the user to set up any list structure format he desires.

    Not all of the variables must appear in the DEFINE statement. The statement DEFINE NODE(ITYP, CV(3), LK(2), IV(2)); describes a node of type ITYP with three alphanumeric values with 20 characters each, two link or POINTER fields, and two integer values. Extract: Summary of FOL
    Summary

    FOL is an attempt to provide the file designer with a convenient means for implementing and manipulating general structured files. FOL is similar in some respects to APL and IDS, but it is also significantly different in other respects: (I) it is implemented in a list processor environment, (2) it does not impose a circular or ring structure on files, and (3) the declaration of record structures is more flexible than in APL and IDS because they are dependent on the less flexible declarations of PL/I and COBOL. In general, FOL gives the user the needed flexibility for developing file organizations for efficient data base design and the command language for manipulating the data.
          in SIGPLAN Notices 10(01) January 1975 Proceedings of the 1973 SIGPLAN/SIGIR Interface Meeting, Gaithersburg, Md., Nov. 1973 view details
  • Sammet, Jean E. "Roster of Programming Languages for 1973" p147 view details
          in ACM Computing Reviews 15(04) April 1974 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 336 view details Abstract: PREFACE  AND  INTRODUCTION
    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 ACM Computing Reviews 15(04) April 1974 view details
  • Abrahams, P. W. review of Claybrook 1974 (LPL) view details Abstract: LPL is a list processing language whose main design goal is to provide list elements (cells) capable of holding a variable number of components of different types, with the number of components of each type determinable at run time. Presently, LPL is implemented as an extension to PL/I, so the syntax resembles that of PL/I, but an independent implementation is planned in the future. Cell types are defined dynamically through the execution of the DEFINE statement, which specifies the type and number of the cell components. A template is created by the system for each distinct cell type. All cells are members of a single doubly- linked list (the "superlist") and have reference counts; garbage collection is managed by scanning the superlist for cells with zero counts and releasing their storage. According to the article, lists can be single-linked, doubly-linked, left-right-linked, multi- linked, or key-linked; but unfortunately, the meaning of those terms is not spelled out. Statements are provided: for inserting cells into lists and deleting them from lists; for deleting cells from all lists in which they occur; for creating and destroying cells; for copying, splitting, and concatenating lists; for adding and removing cells from queues and stacks; and for a number of other operations not worth enumerating here.

    Although LPL is not particularly novel, it does seem to be convenient to use, in comparison, say, with LISP 1.5. The implementation as described is lavish in its use of space; every cell has five fields devoted to system overhead, and since two of them are integers and two are pointers, the space consumption is considerable. The description of multilist structures suggests that there are useful facilities in LPL for operating upon them, but this description is too fragmentary to allow a reliable evaluation of these facilities.


          in ACM Computing Reviews 15(12) December 1974 view details
  • Claybrook, Billy G. "LPL: A Generalized List Processing Language" view details
          in 1974 Proceedings of the NCC&E. view details
  • Claybrook, Billy G. "A file definition facility for file structures" view details Abstract: This paper describes a file definition facility (FDF) for defining files as graph structures. The structure of the file is explicitly declared in the file definition. Primitive functions (from graph theory), operators, and the format of the definition statements are given. The combination of functions and operators appear as directives to the programming system for structuring files. Several simple examples are given to illustrate the use of the FDF. The data organization for the implementation of this facility is described in detail. Problems of considerable importance that are treated are: (1) garbage collection, (2) template construction, and (3) runtime address calculation. The external definitions are represented internally by descriptors. The format of the descriptors is given and a discussion of the items in the descriptors is presented.
          in [ACM SIGFIDET] Proceedings of the ACM SIGFIDET workshop on Data description, access and control, 1974 view details