PL/EXUS(ID:3390/ple003)USer-extensible XPLfor Programming Language/Extended XPL Users' Superset Kendricks and Sitton, Baylor College of Medicine, 1971 Related languages
References: Extract: The Problem The Problem In general, there has existed for many years the need for a high level language for small (mini) computers which had both numerical and string processing capabilities. Recently, many developments in minico1~puter technology have made small machines increasingly more attractive as solutions to fairly complex problems which were, at one time, restricted to much larger machines. These developments include increased CPU speed and power, decreased cost of fast MOS memories and the CPU itself, increased I/O capacity, and increased availability of compatible OEM peripherals. Minicomputers are having an increasing increasing impact in the area of information retrieval and processing, an area which has previously been the domain of large machines. Today's minis, backed by many single-plate or a few multiple-plate disk drives, appear to be very cost-effective for handling large but specific file problems. The storage, access, modification, and processing of patient information, at the level of large clinics, several small clinics, or hospitals, is a problem being faced and solved with small computer systems. For the most part, these systems are custom made for each application and the computer is programmed in assembly language, FORTRAN or MUMPS. The first two of these languages tend to be inappropriate for data base manipulation problems because of the difficulty of programming (assemblers) and lack of string handling capacity (FORTRAN). MUMPS has appropriate linguistic constructs for programming solutions but is highly immobile, has a host of dialects, and is implemented on only two minis at present. Other languages like SNOBOL and COBOL are limited, esoteric, inefficient, and difficult to support on minis. PL/I is very facile, powerful, and increasingly popular language having extensive string and record manipulation capabilities. Although aesthetic and appropriate, PL/I is rare on minis (if at all) and is immobile and too general as well. Mobility has been repeatedly stressed because of the desire to develop a transferable system. Machine dependence was to be minimized in order to preserve the ability to move any useful language and/or system to an installation desiring it, regardless of the minicomputer available. PL/l-like (dialectic) languages are attractive because of their semantic richness and syntactic simplicity and consistency. XPL proved to have the language characteristics and mobility that was desired. XPL is a PL/1 dialect which has several advantages: the compiler (XCOM) is written in XPL and thus is mobile, and the compiler and XPL are implemented on the IBM System 360 series as well as other large systems. Crossmachine compilation is a quite acceptable mode of implementation for a sophisticated high level language compiler. However, XPL per se was not found acceptable for several reasons: XPL programs can run only on large machines at present, XCOM generates only machine instructions, and the semantics of XPL are rather limited for general purpose use. However, XPL is also part of a compiler generating system which allows construction of table driven, bottom-up compilers. It was thus decided to enrich XPL sufficiently and to modify the resulting compiler to generate code for a machine which optimally realized the semantics of the new language. This was done for a machine which, in fact, did not exist but would have to be eventually simulated. Mobility would be achievable by simulating this idealized virtual machine, (i.e., rewriting the interpreter) for a different type of machine. Extract: The Language The Language The new language (called PL/EXUS) is a block structured, procedure oriented, free form source language similar to PL/I. PL/EXUS differs syntactically from XPL only in the declarations. These differences are:
These added data types have a substantial impact on both the semantics and pragmatics of the extended XPL. The semantic enhancement gained by the above changes are the most significant, as far as the power of PL/EXUS is concerned. Fixed length character strings allow one to optionally avoid the inherent inefficiency due to dynamic storage allocation and garbage collection that is incurred in using varying length strings. Fixed length character strings are made more attractive and powerful by the implementation of the substring function (SUBSTR) on the left hand side of the replacement operator (= or :=). Reference can thus be made to any subset of a string for fetching as well as storing, as in PL/I. The use of the SUBSTR function for string construction is more difficult to program than concatenation (the // character), but is much more efficient both in space and time. All strings stored in a fixed length character string are, of course, left justified and padded with blanks. The numerical capabilities of XPL were extended to include real numbers and specificable integer precision. Exponentiation ( ' * * ' ) , log e (LN), e ^ (EXP), exclusive 'or' ('&&'), absolute value (ABS), and square root (SQRT) are provided to enrich the arithmetic syntax. Mixed mode conversion between integers and reals is implicit for all arithmetic, relational, and assignment operators. Input parameters of special functions (intrinsics) are automatically converted as necessary. Matrices and higher level arrays have been added to XPL to facilitate the manipulation of multi-dimensional variables, whether or not the purpose is numerical. Real number constants have been implemented in the full PL/1 version for ease of use and representation. Both real and integer strings are lexically extracted and converted to canonical internal binary numbers. Literal decimal numbers, in virtually any format, may thus be implicitly converted to binary on input. The inverse conversions from binary to integer or real to decimal strings are also implemented for output. Because of this no format statements are required. The EXTERNAL attribute is more a pragmatic, rather than a semantic, enhancement to XPL. XPL, like ALGOL, requires that all procedures (internal sub-routines) to be compiled along with the mainline program as one monolith. In XPL, any forward referenced procedures must be declared in order that all CALLS or implicit invocations may appear before the body of the procedure. As in PL/1, if an undefined procedure is declared in PL/EXUS as an EXTERNAL procedure, linkediting is made possible. Recompilation of an entire system to correct only a few (or possibly one) procedures is thus avoided. The process by which any external variable is linked is simple and fast, since only one external address need be resolved in the program in which the global reference occurs. This capability represents a far more palatable solution to global references and communication than the use of files (as in MUMPS, or ALGOL for example). In XPL, all parameters are called or passed by-value. The addresses of the parameters passed are not available to the called program. Values of actual parameters can not be changed by assignment in the called procedure. In PL/EXUS, this restriction has been removed by allowing actual parameters (excluding expressions or functions) to be passed by-name (address). This is accomplished by appending the attribute NAME to the formal parameter declarations in the procedure definition. Parameters passed by-name can be altered by assignment and thus can be used to return results or output values from a procedure. This again represents a better alternative to using global variables, the procedure as an implicit function, or files to achieve the same result. It should also be noted that cumbersome variables passed by-value (such as long strings) require additional time to move and space to store. Because parameters passed by-name are vulnerable to alteration, they must be used with caution. Constants can also be passed by-name, but are located in a read only memory area and are protected from alteration (contrary to some language implementations, e.g. FORTRAN). Since the primary i!ntent of PL/EXUS was for file and record manipulation, another data type (RECORD variables) was added to PL/EXUS to facilitate this process. RECORD variables are simply an aggregate of (field) variables whose data spaces are contiguously allocated. Since the field variables can not themselves be RECORD variables, this data type is essentially equivalent to a single level structure in PL/I. RECORD variables are thus to be treated as one long bit string with no formatting or conversions performed on I/O. Individual data fields (of possibly mixed types) are accesslble by referencing the name declared for that field, or by subscripting the RECORD variable i t s e l f . In the latter case, REC(I) would reference the Ith data field of the RECORD variable REC. This method is especially useful for processing fields sequentially in a DO loop. In XPL the LITERALLY declaration allows one to associate or equate constants (among other things) with variable names. This particular use of the macro capability permits compile-time variables to be used in declarations where integers are normally permitted. This feature has been extended in PL/EXUS to allow arbitrary integer valued arithmetic or logical expressions in declarations. These expressions may be parenthetically nested and are evaluated according to the same precedence rules as the rLn-time operators. By the use of compile-timex variables, associated groups of run-time variabl(,s can have their sizes or array dimensions changed together according to some predefined function. While this extension still lacks complete generality, it represents an added programming convenience. In general, PL/EXUS represents a more enriched subset of PL/1 than does XPL. This was required since the application of PL/EXUS transcends systems programming, (e.g., conpiler writing). XPL was found to provide a substantial basis for a more general purpose language like PL/EXUS. Although the processing of medical records primarily involves the manipulation of strings, there Is a significant amount of numerical processing required. The capabilities of XPL were thus extended to handle this aspect. Also, because of the interpretive implementation of the language, the string functions in XPL were felt to be too inefficient. The expanded string capabilities in PL/EXUS have alleviated this problem. in Proceedings of the ACM-IEEE symposium on High-level-language computer architecture, November 07-08, 1973, College Park, Maryland, United States view details |