JOSSLE(ID:1231/jos004)Translator languageType checked language with separate compilation using a program library Elements fit in a "committee" metaphor with managers and secretaries Very few structures, but features the DESCRIPTOR type borrowed from CIL, pointers borrowed from SUE, and type extensions borrowed from PASCAL Related languages
References: Reliability considerations had little influence in the design of the first generation of computers. Notable exceptions being, on the hardware side, some circuitry incorporated into the UNIVAC I for checking purposes, and on the software side, the frequency counts employed by von Neumann and Goldstine for measurement purposes. The second generation of computers witnessed a wider interest in hardware reliability while essentially ignoring the software reliability problem. Current computer systems (e.g., IBM/370) incorporate elaborate hardware reliability considerations in their design while continuing to ignore reliable software design. At present there exists great need and interest in making the design of reliable software an explicit problem [i], and in identifying possible approaches for its amelioration. The classical approach of duplication of units is not practical in the case of software design since it is often the case that various programmers working on the same problem arrive at different answers. The situation is compounded further in the case of a large software effort necessitating a sizeable number of programmers. Therefore, other approaches to reliable design are required. Current efforts come from various directions that include:
[...] Structured (programming) system design can be accomplished by employing an available language (e.g., PL/I) in a carefully legislated manner, or through a language specially designed for this purpose. [...] JOSSLE is a language we have designed for the implementation of software that is to be much more reliable than that obtained through conventional languages; other related efforts are [9,10]. A key characteristic of JOSSLE is that it extends conventional structured programming concepts in an attempt to enforce the management strategy described in [6,7]. In other words, and we wish to emphasize this point, the language serves as a tool for the enforcement of system structure! [...] The facilities of JOSSLE that have been described determine the way in which a group of independently compiled programs is organized. In addition to this enforced system organization, there is a definite structure imposed on individual JOSSLE programs themselves. The structure is again a hierarchical one where the function represented by a JOSSLE program is specified in terms of sub-functions. The sub-functions required to represent a higher level function are specified as internal procedures. The structure of internal procedures is essentially identical to that of a JOSSLE program. The main differences are: 1) internal procedures can accept parameters, and 2) the Global Definition Section (see Figure 5) is replaced by a list of identifiers that specifies which resources (programs and data) global to the procedure can be accessed. The identifiers that name the accessible resources are enclosed in the reserved words KNOWN ... END KNOWN. The sections that comprise a JOSSLE program or an internal procedure must appear in the order specified in Figure 5. As a result, the first section of a program or procedure explicitly states which shared (global) information structures are accessible. Finally, the flow of control through a JOSSLE program is readily apparent since a restricted set of control structures are available. The control structures provided represent a disciplined form of branching and consist of: I) sequential statement selection; 2) selection of a statement from a group of alternatives; 3) iteration, and 4) procedure call. The syntax of statements that specify the above control structures is described in [11]. [...] The structure imposed on a system of programs by JOSSLE is a hierarchical one in which a Communication Region represents an abstraction of a function that is implemented in terms of Member Programs. The data connections between functions are explicitly represented by the Communication Region and the Global Section of each Member Program. In addition, control connections between functions are readily apparent since: 1) a Member Program can only call other Member Programs on the same level, 2) lower level Member Programs are activated by calling the Communication Region that represents the abstraction of the lower level function, 3) the possible control paths (i.e., accessible Member Programs) are explicitly stated in the Global Section of each Member Program, and 4) control always returns to the statement following a call. In terms of the programming management strategy discussed in the introduction, theChief Programmer is responsible for the function represented by a Communication Region and its Member Programs. A Member Programmer would, in turn, be responsible for a particular sub-function (Member Program). Sub-functions that are sufficiently complex weuld be defined in terms of a Communication Region and Member Programs. In this case, a Member Prograrmaer at one level becomes a Chief Programmer for the next lower level. Maintaining the information contained in the Communication Region is the responsibility of the Programming Secretary. The system structure imposed by JOSSLE models, in essence, the Chief Programmer team management strategy. Taken together the two form a powerful tool for exploiting design methodologies that lead to reliable software systems. Abstract: This dissertation describes the design, development, and implementation of JOSSLE, a high-level language tailored to the problem of specifying the post-syntactic (i.e., semantic) phase of programming language translators. The basic objectives of the language are to: 1) reduce the effort required to implement a translator for a programming language; and 2) increase the probability that the resulting translator will be a reliable piece of software. The problem of generating code is treated in detail, and three basic code generation functions isolated. From this a set of machine independent code generation primitives are developed, and their implementation on the System/360 described. The basic functions required during the semantic phase of translation are then discussed along with the features of the JOSSLE language that enable these functions to be effectively accomplished. In particular, the language contains a simple, yet flexible, way of structuring information and a powerful set of machine independent code generation statements. The problem of developing reliable software is described next, and the facilities in the JOSSLE language that can lead to such software are discussed. The language can be an extremely useful tool in developing reliable translators since: 1) a restricted set of control structures are available; 2) a definite structure is imposed on the organization of a single program; and 3) a definite structure is imposed on a system of independently compiled programs. JOSSLE has been implemented on the IBM System/360 and forms a basic part of the UCSB Translator Writing System. The language has been used as both a research tool in language design, and as an instructional tool in teaching the translation of programming languages. in [ACM] Proceedings of the 1973 annual ACM conference Atlanta, Georgia, United States view details in [ACM] Proceedings of the 1973 annual ACM conference Atlanta, Georgia, United States view details in Rosenfeld, Jack L. (Ed.): Information Processing 74, Proceedings of IFIP Congress 74, Stockholm, Sweden, August 5-10, 1974 view details in ACM Computing Reviews 16(02) February 1975 view details A one pass compiler for JOSSLE has been constructed for the IBM System/360 family of computers, and the language constitutes an integral part of a translator writing system under development at the University of California, Santa Barbara, and the University of Connecticut. External link: Online copy Extract: Introduction The ability to design and correctly implement large programming systems (e.g. language translators, operating systems) is one of the principle challenges that faces the computer field. In particular, this challenge can be viewed as one of providing an environment in which: (a) the time and effort necessary to implement a programming system is reduced; and (b) the probability is increased that the resulting product will be a reliable piece of software. In our work on translator writing systems we have focused on the problem of creating a natural environment for the construction of reliable programming language translators. The general approach is to: (a) automate those aspects of translator construction that can be made language independent; and (b) provide a set of tools for specifying the language and machine dependent aspects of translation. The JOSSLE language is such a tool. It exists for the purpose of providing a flexible and systematic way of specifying the post-syntactic (semantic) phase of programming language translation. In this paper we describe the main features of JOSSLE, its environment, and the rationale that guided its design. Extract: Structures in JOSSLE Information structures The development of data definition and data structuring facilities for the JOSSLE language was governed by the nature of the post-syntactic phase of the translation process. Except for code generation, this phase is generally responsible for tabulating semantic information (e.g. symbol name, type, run-time address) as it becomes known. Rather than attempt to support an elaborate array of data types and structures, the philosophy in JOSSLE is to provide a few primitive data types, a data definition facility, and one basic information structure. Primitive data types The five primitive data types in JOSSLE were chosen because of their applicability in translator writing. The first three, INTEGER, BIT(n), and CHAR(n), represent integer numbers, bit strings, and character strings respectively. The fourth type, DESCRIPTOR, is an extension of a concept introduced in CIL (Gries, 1969). Variables of type DESCRIPTOR represent complete descriptions of either run-time information structures or run-time control structures and serve as operands in code generating statements. The ability to indirectly reference information is an important feature in the development of translators. The incorrect use of pointers, however, can be an endless source of trouble. In line with the goal of aiding in the detection of logical errors, the types of all operands in an operation are checked at translation time. No automatic type conversion is performed, thus the mixing of types is not permitted. The conventional use of pointers violates the above philosophy since complete translation time type checking cannot be performed on the contents of pointers. As a result, JOSSLE does not contain the type POINTER. Instead, in JOSSLE, as in the system language for project SUE (Clark and Horning, 1971), pointer-to another type (denoted PTR2A (type)) is a primitive type. With this approach it is assured that the type that results from dereferencing a pointer is known at translation time. Type definitions The JOSSLE language contains a simple type definition facility that is a subset of a similar facility introduced in PASCAL (Wirth, 1971). A user defined type, as shown in Fig. 2, consists of a set of components. Each component is composed of an identifier (component name) followed by a type specification. The type of a component can be either a primitive type or another user defined type. The example in Fig. 2 defines two new types. The first of these; ST-ENTRY, contains three components: NAME, a character string; TYPE, a bit string; and RTADDR, a description of a run-time variable. In the second definition the component SEMANTICS of the type STACLENTRY has been defined to contain pointers to variables of type ST-ENTRY. The only operation in JOSSLE defined for all types (user defined or primitive) is replacement. A component of a variable whose type is user defined can be accessed, and thereby manipulated, by qualifying the variable name with the component name. If the type of the resulting value is not primitive, further qualifications may be necessary. Data structuring The JOSSLE language contains as its basic information structure a linear list (i.e. one dimensional array). As shown in Fig. 3, the declaration of a linear list involves a specification of the name of the list and the number and structure of its elements. For example, in Fig. 3 SYMBOL-TABLE is defined to be a linear list of 100 elements where each element is a variable of type ST-ENTRY (defined in Fig. 2). The linear list along with the simple data definition facility described above is proving to be a straighforward and sound base for translator construction. Control structures The objective of encouraging the development of programs whose control structures are explicit greatly influenced the selection of control mechanisms for the JOSSLE language. The mechanisms selected represent a disciplined form of control transfer and are based on the observation of Bohn and Jacopini (1966) that the control structures of sequential flow, conditional selection, and iteration are sufficient to implement any algorithm. Much attention has been given to the usefulness and desirability of the GOT0 statement (Leavenworth, 1972; Hopkins, 1972; Wulf, 1972; Dijkstra, 1968). Rather than include it in the language and hope that it is never (or rarely) used, it has been eliminated. The basic mechanism for statement selection in JOSSLE is the CASE control structure. As shown in Fig. 4, the CASE structure specifies that the next statement to be executed is to be selected from a group of alternative statements. If the value of (expression) in the case header is of type integer, the ith statement in the group (counting from zero) is selected for execution. If, however, the value of the expression is a bit string, the leftmost bit of the string is tested. The first or second statement in the group is then selected according to whether the value of the bit is '1' or '0' respectively. Iteration is accomplished in JOSSLE with the LOOP control structure shown in Fig. 5. Use of this structure results in unbounded repetition of the statements within the brackets LOOP.. . END-LOOP. An exit statement is provided to terminate the execution of a loop. This termination can be either unconditional (EXIT) or conditional (EXIT WHEN (expression)). During translation the JOSSLE compiler checks each loop to insure that it contains at least one exit statement. The LOOP control structure was chosen over the conventional DO-WHILE statement since the point in the loop at which termination conditions are evaluated is specified by the user. The structure of JOSSLE programs and procedures is important in the hierarchical development of a translator. As shown in Fig. 6, each consists of five basic sections. The Global Definition Section establishes the environment in which the JOSSLE program is to execute. This involves a declaration of the external variables through which independently translated programs communicate. The environment of a procedure is simply its enclosing scope. The Known Section lists those variables that can be accessed by the procedure and thus explicitly states possible side-effects. The remaining four sections are identical for both programs and procedures. These sections specify the user defined types, local variables, internal procedures, and executable statements of the associated program or procedure. A detailed discussion of the hierarchical structure imposed on a system of JOSSLE programs is contained in White and Presser (1973). Since the procedure definition section precedes any executable statements, the types of all formal parameters are known before any procedure calls are translated. Consequently, all actual parameters can be type checked before control is ever passed to a procedure. The execution of a procedure is terminated with the RETURN statement which transfers control to the statement immediately following the one that invoked the procedure. The RETURN statement can return a value (RETURN WITH (expression)) in which case the enclosing procedure is considered a function. All parameters are passed by value; however, since pointers can be parameters, the effect of call by reference is possible. The information and control structures described above, along with assignment statements and BEGIN. . . END groups, constitute the basis of our programming language. To make this language a powerful tool in translator writing, a code generation facility has been incorporated into it. in The Computer Journal 18(1) view details In contrast to the quite extensive literature covering the syntactic phase of programming language translation, the compiler writer is faced with a relative paucity of systems and languages designed expressly for the provision of semantics. Consequently, one's initial reaction upon encountering a paper of this nature is one of hopeful anticipation. However, the language described here proves to be a disappointment in its failure to introduce more than a single innovation to aid the process of compiler writing. That departure is the provision of a simple type DESCRIPTOR as a compile time description of a runtime information or control structure. This would aid considerably in the implementation of non- simple source language data-types (arrays and structures). Aside from this feature, however, it is difficult to identify any benefit derivable from the use of JOSSLE rather than a conventional high-level language such as PASCAL or PL/I for this purpose. JOSSLE is, indeed, at the same semantic level as these languages. It has, for example, no mechanism to aid the implementation of ALGOL-like block structure and scope checking; the user of JOSSLE must invent a mechanism for this in the same way (and with probably the same result) as the user of PL/I. Although JOSSLE might be of some interest as a pedagogical tool, its use without considerable extension in writing a compiler for any reasonably sized language is not to be recommended, and the provision of JOSSLE interpreters for a wide class of machines, adequately exploiting the architecture of such machines, would require an effort of unwarranted size. in ACM Computing Reviews 17(02) March 1976 view details Separate compilation of program units is a practical necessity. Its basic goals are to permit the separation of large programs into simpler, more manageable parts, and to create libraries of program units. Separate compilation helps to reduce compilation costs and to simplify the development and management of program corrections and modifications. For large projects involving several programmers, separate compilation permits program texts to be separated physically in a way that reflects the division of work and responsibilities. Once the common interface between two parts has been agreed upon and recorded, the two parts can be developed and compiled separately. The fact that the common interface is a physically separate text guarantees that separate recompilation of either part does not invalidate the common interface. The physical separation of program texts may be viewed as a support facility for the structured programming concept of refinement. It may also be used to conceal the text of a subprogram body from users who are only allowed to call the subprogram. Such concealment may be justified either for reasons of confidentiality or in order to prevent the user from inferring implicit properties or making assumptions regarding the functioning of the subprogram. Finally this physical separation facilitates the construction of libraries and reusable software components. It is appropriate at this stage to introduce the distinction between independent and separate compilation (following J.J. Horning). Independent compilation has been achieved by most assembly languages and also by languages such as Fortran and PL/1. Compilation of individual modules is performed independently in the sense that the modules have no way of sharing knowledge of properties defined in other modules. Independent compilation is usually achieved with a lower level of compile-time checking of consistency between units than is possible within a single compilation unit. In consequence, independent compilation came into disrepute and was rejected by safety-minded early typed language definitions such as Algol 68 and Pascal. Fast compilation of the complete program was often advocated by promoters of these languages as a safe alternative to independent compilation. However, fast compilation has its limits, and it fails to answer the needs of confidentiality and libraries. Separate compilation, on the other hand, reconciles type-checking safety and the pragmatic reasons for compiling in parts. It is based on the use of a program library which contains a record of previous compilations of the units that form a program. It has been developed in the language Sue and in later languages such as Lis, Jossle, Mesa and later extensions of Pascal and Algol 68. We next discuss its properties in terms of what is provided in Ada. When a program unit is submitted to the compiler, the compiler also has access to the program library and is therefore able to perform the same level of checking (in particular type checking) whether a program is compiled in many parts or as a whole. It is the existence of the program library that makes the compilation separate but not independent. Using the general information available in the program library, the compiler will be able to assist the user in organizing recompilations. In particular, it will be able to display information about the current state of the compilation of a program that is divided into several compilation units: which separate program units have been compiled, and which need to be recompiled because of prior recompilations. It is thus for reasons of safety and utility that Ada offers a powerful facility for separate compilation. Two additional criteria have been followed in this design, namely simplicity of use and simplicity of implementation. Separate compilation being a user-oriented facility, it should be simple to understand and use. Consequently it should not introduce other concepts than those required by the nature of separate compilation. Scope rules and the general form of separately compiled program units should be similar to those of other program units. In addition, separate compilation should be implementable simply and efficiently. The additional work required for separate compilation should stay within reasonable limits, since one of the goals is to save overall compilation and recompilation time. in ACM Computing Reviews 17(02) March 1976 view details |