PLITRAN(ID:7007/pli009)PL/I PreprocessorMacro preprocessor for PL/I Bayes, IBM Australia, 1968 Related languages
References: The method is briefly compared with other approaches to compiler-compilers, and with the PL/I compile time facilities. Extract: The need for special purpose languages The need for special purpose languages Today the computer user has available a wide variety of programming languages, ranging from the general purpose to the very specific. In System /360, for instance, the most general language is Assembler, followed by PL/I. Fortran, Cobol and Report Program Generator (RPG) specialise to the extent of major application areas. These are followed by a wide range of languages for simulation, data base enquiry, mathematical programming and other applications. It is generally true, that the more specialised the language, the more succinctly and elegantly the problem can be stated, provided the problem lies within the range of the language. The programmer, by choosing a language, is choosing a program structure, a range of data types and a set of instructions. Hence these choices need not be made within the program. There is no doubt that the special purpose language is a valuable tool, and that the number of languages will increase as new applications are developed. The disadvantage of a special language is that the programmer may occasionally require features which are not available in the language, or are available in an inefficient manner. An example is bit string manipulation in Fortran. The ability to call assembler subroutines for these purposes is not a happy solution to the problem. The ideal language would provide brevity in its own problem area, whilst at the same time provide a capability for a wide variety of data processing requirements. Furthermore, we would like (his capability to be provided in the same way over a wide range of languages. For instance, in any two languages, neither of which is designed to facilitate file handling operations, the instructions for file handling would be written in an identical way. Thus we envisage a spectrum of languages, each of which is unique only in its area of specialisation. We postulate a primitive or basis language. An application language is an extension of capability of the basis language, in some particular area. From the user point of view this approach has advantages in education, standardisation and interchangability of program coding. Extract: Introduction to PLITRAN INTRODUCTION TO PLITRAN PLITRAN is a body of coding designed to aid the writing of translators for special purpose application languages. A translator translates the language to PL/I text; this is then compiled and executed. The definition or description of the translation required is written in PL/I. This description is inserted in PLITRAN. and the resulting deck is the required translator program in PL/I. To avoid confusion, we shall name the three texts involved in the translation process. We call the description or definition of the language the description text. Statements written in the defined language we call the source text. PL/I resulting from the translation of the source text we call object text. Description text is written by a programmer; source text, by an application programmer. The application programmer need only know the application language, providing this is wide enough to cover his needs. The programmer needs to know PL/I. He also needs the conventions and notation for defining a language, as described in this and the following sections. PLITRAN analyses the source text and inserts information into tables for the programmer to use. The nature of this analysis dictates some characteristics of the source text. In particular, it will normally have the following features: 1. It is composed of statements which terminate in semicolons. 2. Identifiers are defined and delimited in a manner compatible with PL/I. 3. Operators, comment delimiters and quotation marks have the same meaning as in PL/I. Any language defined using PLITRAN can be used as an extension of PL/I. Language statements and PL/I statements can be intermixed in the source language. (To make use of this facility the application programmer will need to know the conventions by which the object text is produced.) PLITRAN does not provide a full syntactical analysis of the source text. It is clearly necessary that language source text shall be distinguishable from PL/I. PLITRAN is oriented to the assumption that language statements can be distinguished from PL/I by the presence of keywords in prescribed contexts. Provided none of the keywords are PL/I keywords, the full facilities of PL/I remain available. The use of the keyword concept can be quite flexible. For instance, suppose a new data type is required. The declaration that a variable name represents the data type will cause the name to be added to the list of keywords (or to a new list). The subsequent appearance of the name in a statement could then trigger the appropriate action. PL/I keywords can be used with discretion. For instance, READ CARD; could be a valid language statement, because the PL/I keyword READ is never used in a statement which contains only two words. Extract: PLITRAN variables and subroutines PLITRAN variables and subroutines PLITRAN reads source text a statement at a time. The text is placed in an input buffer and is available to the programmer. In addition, PLITRAN analyses the statement and stores information in tables for the programmer to use. A word table stores information on identifiers, numeric constants and string constants. To PLITRAN, an identifier is a string of alphameric characters starting with a letter, a numeric constant is a string of alphameric characters starting with a number and a string constant is a string of characters enclosed in quotation marks. The table stores pointers to the start and end of each word in the input buffer, and the parenthesis level of the word. Another table stores equivalent information for selected punctuation symbols, namely periods, colons, commas and semi-colons. Other variables contain the number of words in the statement, the number of punctuation symbols, and a pointer to the terminating semi-colon of the previous statement. The following subroutines have currently been implemented: ANY is a built-in function with character string argument. It returns the position of the word which matches the argument. If the argument does not exist as a word in the current statement, ANY returns the value zero. REPLACE is a subroutine with two arguments, a number and a character string. The word whose ordinal is the number is replaced in the input buffer by the string. For instance, if the first argument is 6, then the sixth word is replaced. An alternative entry point permits the replacement of an arbitrary area in the buffer. Characters are moved in the buffer to allow an exact fit of the replacing text. WITHIN is a built-in function which returns a character string from the input buffer, the limits of the area being defined by pointers. BETWEEN is similar, except that the area is defined as being between nominated words. OUTPUT is a subroutine with a character string argument. The argument is written to the object code data set. This routine suppresses the copying of the current statement to the object text. NUMBER is a built-in function with a numeric argument. It returns a character string representing the number whose ordinal value is the argument. IDENT is a similar function for identifiers. In execution, PLITRAN is controlled by a number of parameters. These control the size of the tables and the input buffer, the source and object text margins, the printing of source text and object text, and the printing of diagnostics. Three levels of diagnostics are provided. The lowest level occurs when the buffer or a table overflows. When this happens the current statement is flushed unchanged to the object text, and a warning message may, optionally, be printed. A higher level of diagnostic occurs when a subroutine is called with invalid arguments. Processing continues, but the object text will normally be invalid. The highest level corresponds to a PL/I ERROR condition. This, causes the object text to be dumped and the run to be terminated. The philosophy with diagnostics is to print a self-identifying selective dump of the relevant variables. The programmer can then find his own mistakes. Extract: How to use PLITRAN How to use PLITRAN A set of coding to compile a language feature is called a module. It is highly desirable that independently written modules can be combined together to run in the same program. This will allow the accumulation of a library of language modules, so that, hopefully, any new language can be built partly by selecting modules from existing languages. There are three possible areas of conflict between modules: 1. The names of identifiers used in coding the modules conflict, 2. The keywords in the application languages overlap, 3. When new variables are generated in the object text, their names may overlap. To solve (1), each module should be coded as an internal procedure. All variables should be explicitly declared. The "scope of names" rule in PL/I then ensures that identifiers will remain distinct. To solve (2), the keywords should be passed as arguments to the module procedure, and coding inside the procedure should use the associated parameters. To solve (3), all new identifier names in the object text should start with a character string which is passed to the procedure as an argument. This rule will also ensure that the application programmer can easily know which names he must avoid using in his own coding. We now describe three examples of the use of PLITRAN. Extract: Other approaches to compiler generation Other approaches to compiler generation The computer literature describes many examples of generalised processors for programming languages, compiler-compilers, metacompilers and the like. Feldman and Gries (1968) contains an excellent survey of these systems. It is a noticeable feature of many of these systems, that the metalanguage has not been used to describe the process by which a program in the metalanguage is translated into a compiler. In this case, there is thus at least one important application for which the metalanguage is unsuitable. In PLITRAN, we regard a computer which is equipped with a PL/I compiler as conceptually equivalent to a machine for which PL/I is the object code. This has advantages when writing a compiler. It has double advantages when writing a compiler-compiler. This is why PLITRAN can define itself easily and has been quick to implement. The disadvantage, as has been mentioned, is that we are restricted to languages whose range of application does not exceed the range of PL/I. The PL/I compile time facilities (IBM) provide a macro facility for PL/I. Statements to manipulate PL/I text are written in a very restricted subset of PL/I. Compile time statements are intermixed with the PL/I statements, and are distinguished by a leading % sign. The compile time facilities are primarily intended to reduce the clerical effort required for writing programs. Character string substitution is provided and a primitive arithmetic facility is available for logic control within the compile time program, and for creating numeric values in the output text. The compile time facilities provide no syntactical analysis of statements, and are therefore unsuitable for the type of application envisaged for PLITRAN. To a large extent, PLITRAN and the compile time facilities are complementary, though the simpler features of both overlap. |