Modula(ID:771/mod019)

Concurrent modular language after Pascal 


MODUlar LAnguage. Wirth, 1977.

Predecessor of Modula-2, more oriented towards concurrent programming but otherwise quite similar.


Related languages
Pascal => Modula   Evolution of
Modula => LUKKO   Influence
Modula => Modula/R   Extension of
Modula => Modula-2   Evolution of
Modula => SB-Mod   Extension of

References:
  • HOLDEN, J. and WAND, I. C. (1977). Experience with the Programming Language MODULA, Proceedingsof IFACIIFIP Real Time Programming Seminar, Eindhoven, K. Smedema (editor), Pergamon Press. view details
  • Hoppe, Jiri "A comparison of MODULA with other system programming languages" pp129-134 view details
          in Proceedings of the Fifth International Computer Symposium, 1977 view details
  • Wirth, N. "Modula A Language for Modular Multiprogramming" pp3-35 view details
          in Soft Prac & Exp 7(1) Jan 1977 view details
  • Wirth, N., "The Use of Modula", pp37-65 view details
          in Soft Prac & Exp 7(1) Jan 1977 view details
  • Barnard, D. T., W. D. Elliott, et al. "Euclid and Modula." view details Abstract: Both Euclid and Modula are programming languages based on Pascal and intended for writing system software such as operating system kernels. The further goals of each language, however, resulted in two rather different languages. Modula is meant to be used in multiprogramming systems primarily on mini-computers; thus Modula aims for very small run-time support and efficient compilation by a small compiler. Many of the Euclid language design decisions, on the other hand, were influenced by the authors' overriding concern for the ability to verify Euclid programs. This paper discusses design goals of the two languages and the language differences that resulted. After contrasting individual features of the two languages, modules and multiprogramming are discussed in more detail.
          in SIGPLAN Notices 13(03) March 1978 view details
  • HOLDEN, J. and WAND, I. C. (1978). An Assessment of MODULA, Software-Practice and Experience. In press. view details
          in SIGPLAN Notices 13(03) March 1978 view details
  • Barnes, J. G. P. "The development of tasking primitives in high level languages" in Real-time data handling and process control. Proc. first European symposium (West Berlin, Oct. 23-25, 1979), North-Holland Publishing Co., Amsterdam, 1980, pp235-241 view details
          in SIGPLAN Notices 13(03) March 1978 view details
  • Ernst, George W.; Ogden; William F. "Specification of Abstract Data Types in Modula" view details Abstract: The programming language MODULA is extended to permit the formal specification of the structure and functional capabilities of modules. This makes true hierarchical programming possible in MODULA by allowing programmers of higher level parts of a system to ignore completely the internal structure of lower level modules and to rely entirely on the specifications of the capabilities of these modules. An example is included to illustrate this technique. We show that our specification mechanisms are sufficiently powerful to support formal verification rules for modules that have disjoint representations for abstract objects.

          in TOPLAS 2(4) October 1980 view details
  • Wand, I. C. "Dynamic resource allocation and supervision with the programming language MODULA" view details Abstract: The programming language MODULA was designed by Wirth to be suitable for programming in areas previously the preserve of Assembly code. Examples of these areas are process control systems, computerised laboratory equipment and input/output device drivers. Experiments with MODULA have shown that the language is quite successful for coding single programs that run on dedicated computer systems, but that it is less successful in applications that require dynamic resource management, both of storage and of processor time.
    In this paper we define extensions to MODULA that enable the language to be used for the coding of storage allocators and process supervisors. At the same time an exception handling mechanism is introduced for the convenient handling of the error situations that arise during such programming. The exception handling mechanism turns out to have other uses, such as variable initialisation and process exit code. The consequences of an exception handling mechanism suitable for interactions Mween processes are examined.
    Finally, some estimate is made of the further complexity introduced into an existing simple language, both into its definition and into the compiler. Possible areas of use are mentioned. Extract: Modula
    MODULA is a simple programming language proposed by Wirth (1977a) for use in programming areas still dominated by Assembly code, such as process control, computerised laboratory equipment and input/output device drivers. Coding exercises in MODULA by Wirth (1977b) and others (Holden and Wand, 1978) have shown that the language is quite successful in these areas of application and is particularly good for the expressioh of single programs that will run on dedicated computing equipment.
    However the language does have a number of drawbacks if it is to be used for the coding of operating systems kernels or for the writing of any software component where supervision plays an important part. In particular these difficulties centre upon
    (a) a process supervising other processes
    (b) a storage allocation process and
    (c) the general handling of error conditions at both the process and module level.
    It is interesting to note that these are all requirements of the so-called 'Ironman' language (1977).
    This paper examines extensions to MODULA which attempt to overcome these drawbacks. A new storage mechanism is proposed based upon a declared type called a region which is very similar to the implicit heap in PASCAL. For references into such storage, PASCAL-like pointers are proposed. In addition it is proposed that processes and their storage must be allocated within a region, although it is not suggested that device processes should be included in this new mechanism. Thereafter references to ordinary processes must be made via pointers, and, furthermore, when a process is run it can be executed for a given number of signal occurrences (usually originating from a device process) under the supervision of a parent process. By this mechanism supervisory processes can be constructed which can then make sure that a process can only run for a limited period and can subsequently terminate that process if necessary. An exception mechanism is proposed for transmitting error conditions; however the mechanism can be used quite generally.
    We suggest that these extensions will cause moderate complications in the language definition and in the compiler. The major run time complication is in the storage allocation mechanism which implies a PASCAL-like heap within every region, although with the simplification that any region is allocated within the storage space of the parent process. In conclusion we suggest that the facilities proposed will enable a MODULA-like language to be used for the coding of basic operating system components. Extract: Modula vs GYVE vs EUCLID
    Note that this proposal certainly lacks the flexibility of GYVE
    pointers (Schwartz and Shaw, 1976) or the completeness of the
    Euclid (Lampson et al., 1977) visibility rules. However it is
    suggested that the simple rules of MODULA, together with the
    modification suggested here, will deal with the majority of
    practical cases.
          in The Computer Journal 23(2) 1980 view details
  • Steensgaard-Madsen, J. " Statement-Oriented Approach to Data Abstraction" pp1-10 view details Abstract: The term data abstraction denotes the characterization of data usage independently of implementation details. Current work has concentrated on the elaboration of the type concept for the purpose
    of expressing data abstraction. In this paper a more statement-oriented approach is taken and a powerful mechanism is obtained via rather simple means. Programming language constructs that express data abstraction are proposed, and examples of their use are given. The proposal relies heavily on the concept of parameters. To obtain a useful mechanism types are allowed as parameters. Extract: Introduction
    1. INTRODUCTION

    Programming languages traditionally offered procedures and functions as the only means of abstraction, that is, of providing powerful and high-level concepts while suppressing the details of their realization. The last ten years have seen many efforts to devise better abstraction facilities. SIMULA 67, Concurrent PASCAL, MODULA, CLU, and MESA are some of the newer languages offering abstraction mechanisms.

    The facilities offered by those languages are intended to hide by abstraction the interplay of different operations on the same data and to prevent access to the common data except by use of the abstract operations. Most researchers have looked to the type concept as a basis for an abstraction mechanism. However, no single type-based approach has been generally accepted.

    The approach taken in this paper differs from previous ones in a fundamental way. It is not based on a generalization of the type concept. Instead, the emphasis is on statements and procedures.

    The syntax we introduce is similar to that used for other proposed abstraction mechanisms. In order to avoid confusion, the reader must initially assume a simplified notion of types. A type is considered to be a set of values. From a theoretical point of view a type is considered to be a set component of an algebra, and a distinction is made between an algebra and its sets of values. This attitude differs essentially from Guttag and Horning's [5]. The algebra itself can be identified with other parts of this proposal, but this is not done explicitly here.

    This paper introduces the proposed language constructs in steps, each including examples. Section 2 concentrates on how to use an abstraction; it is divided into subsections of increasing complexity. Section 3, showing how abstractions are defined, is also subdivided according to complexity. Section 4 specifies the semantics using rewriting rules and thus indicates a possible implementation. Section 5 presents some final remarks.
          in TOPLAS 3(1) January 1981 view details
  • Wetzel, G. F. review of Barnes 1981 (CSP, Green, Modula) view details
          in TOPLAS 3(1) January 1981 view details