Modula-2

from Wikipedia, the free encyclopedia
Modula-2
Paradigms : imperative , structured , modular
Publishing year: 1978
Designer: Niklaus Wirth
Developer: Niklaus Wirth
Influenced by: Pascal
Affected: Lua , Oberon , Seed7 , Modula-2 + , Modula-3

Modula-2 is a 1978 further development of the Pascal programming language and, like this, was developed by Niklaus Wirth . The main characteristics of Modula-2 are the language features for the modularization of programs. Modula-2 itself later served as a template for the Oberon programming language .

Emergence

In 1977/78 Wirth got to know the pioneering architecture of the Alto workstations at the Xerox Palo Alto Research Institute , which already had a mouse, graphic screen and window technology. The Alto was programmed in the Pascal-like programming language Mesa . After his return to ETH Zurich , Wirth and his group began developing their own workstation, later called the Lilith , where hardware and software were developed in conjunction.

Standard Pascal, which was developed as a language for programming lessons, was not suitable for programming an operating system for the Lilith, for two main reasons:

The new language, which was named "Modula", therefore contained two new concepts compared to Pascal (in addition to several changes in the syntax ):

Modula only became known outside the ETHZ in the Modula-2 version. The clear separation of definition and implementation in separate files (usually with extension DEF or MOD) was trend-setting and was copied by later programming languages, but its clarity was not achieved. Modula-2 later had successors that were independent of Wirth, such as Modula-2 plus and Modula-3 . Since 1996 there has been an international standard ISO / IEC 10514-1 for Modula-2.

properties

Since Modula-2 is a further development of Pascal , it is sufficient to go into the main differences to this language.

Modules

The most prominent innovation in Modula-2 are the modules as devices for modular programming according to the ideas of software technology , first expressed by David Parnas . The main program is therefore also called MODULEinstead of PROGRAMas in Pascal. All parts compiled separately from the main program must be split into two files: One DEFINITION MODULEonly contains the description of the interface of the module, that is: it lists the constants, types, variables and procedures that are made available for other modules ("exported") should be. A separate one IMPLEMENTATION MODULEthen indicates the implementation.

In terms of strict modularization, it is logical that concepts such as input / output and mathematical functions, which were part of the normal scope in Pascal, are not included in the Modula-2 language. If necessary, they must be imported from the modules provided for this purpose (usually InOutfor input / output and MathLibfor the mathematical functions).

Data types

The Lilith should have a word length of 16 bits. Whole numbers would therefore have had a range from -32,768 to +32,767, which Wirth found to be too great a limitation. In addition to the data type INTEGER, Modula-2 received a data type CARDINALfor the non-negative numbers between 0 and 65,535. Mixed expressions containing both INTEGER- and - CARDINALpartial expressions were prohibited. Therefore there are general ways to transform types:

  • Type conversion functions VAL(Type , Expression) convert an expression so that it belongs to the new type, while
  • Type transfer functions (" type casts ", at Wirth: " type cheats ") of the form type (expression) leave a bit pattern unchanged and only change the data type for the compiler.

For example, VAL(CARDINAL,-1)an error message yields while CARDINAL(-1) = 65.535applies.

An innovation compared to Pascal is also the data type PROCEDURE, with which a weakness of Pascal was to be remedied: In Pascal it was possible to pass a function to a procedure as an argument, identified by the keyword . However, it could not be checked whether the number and type of the parameters that were actually transferred later were actually suitable. However, if you declare in Modula-2 for example FUNCTION

   TYPE myFunction = PROCEDURE (INTEGER): REAL;

so when calling a procedure (the keyword FUNCTIONdoes not exist in Modula-2) 

   PROCEDURE myProcedure (f: myFunction; n: INTEGER): REAL;

the compiler will determine with each call of myProcedurewhether the currently ftransferred function has the correct type. Since procedures are completely normal data types, it is also possible to incorporate them in other data structures such as ARRAYs and RECORDs.

Control structures

To avoid numerous BEGIN- ENDbrackets in Modula-2, the IFand WHILEinstructions are each terminated with a END. GOTOThere is no such thing as Pascal's familiar , but there is a LOOP- EXIT-construction.

The pseudo module SYSTEM

As the language for operating system programming, Modula-2 had to have facilities to access details of the underlying machine. There was a separate module for this SYSTEM, from which the data types WORDfor a non-specific memory word and ADDRESSfor a memory address could be imported, as well as a function ADRfor determining the memory address of a construct and TSIZEfor determining the memory size for a certain data type. In addition, there are the already mentioned functions for concurrent programming.

SYSTEM is called a pseudo module because there is neither a definition nor an implementation part, but all knowledge about this module is built directly into the compiler.

development

There are two dialects of Modula-2. On the one hand PIM , the variants developed by Niklaus Wirth and defined in the standard work "Programming in Modula-2". According to the editions of the book, there are the second, third and fourth variants of PIM. The language was changed slightly with each edition. The second dialect is ISO , the variant developed by an international committee (under the umbrella of the International Organization for Standardization ).

  • PIM2 (1983): Explicit EXPORT in definition modules .
  • PIM3 (1985): Explicit export in definition modules no longer necessary.
  • PIM4 (1989): Specification of the behavior of the MOD operator when the operands are negative.
  • ISO (1996): The aim during the development of ISO Modula-2 was to resolve the ambiguities of PIM Modula-2. In addition, the data types COMPLEX and LONGCOMPLEX , exceptions, the module termination ( FINALLY clause) and an extensive standard library for input and output have been added to the language - along with a number of minor changes.

Implementations

Modula-2 achieved relatively great popularity in the late 1980s , especially in the version from Jensen and Partners International (JPI), which had a 10-window editor in its development environment for MS-DOS and a very fast compiler with well-optimized object code put on the market. Later versions of it were called TopSpeed ​​Modula-2 ; C and C ++ were also included in the development environment .

Current Modula-2 compilers:

criticism

Wirth himself lists the following problems with Modula-2 in connection with the development of Oberon:

Qualifying imports

The recommended method of using components from other modules is 

IMPORT M;

This removes all of Mthe exported identifiers by so-called qualified identifiers , such as M.A, M.Bavailable. Alternatively, Modula-2 knows the qualifying import 

FROM M IMPORT A,B;

With this import the identifiers are then simply available in the form Aor B; the origin from the module Mis then no longer directly visible at the point of use. This allows programmers to make mistakes. Qualifying imports are therefore no longer available in Oberon.

Export of enumeration types

If a module contains the exported type 

TYPE Ampel = (rot, gelb, gruen);

according to the logic of the language, an import of this type only refers to the type name ( Ampel), but in reality the names rot, gelband are also gruenimported, which can confuse the programmer in the event of identifier conflicts at the point of use. In Oberon there are no longer any enumeration types, because otherwise it would not be possible to prevent their export.

Data type CARDINAL

Unsigned arithmetic works very differently than signed arithmetic; therefore, expressions in which unsigned and signed values ​​occur simultaneously are problematic. Modula-2 has therefore forbidden such mixtures in principle, which met with protests from the programmers because the programs were unnecessarily complicated by the use of type conversion functions. In addition, asymmetries arise in the treatment of certain program structures and in the mathematical modulo function ( MOD).

Type transfer functions and other low level devices

The type transfer functions ( type casts ) make it possible to discover properties of the underlying machine that should actually remain hidden from the programmer of a high-level programming language, such as endianness , i.e. the question of the order in which the individual bits of a machine word are stored. Depending on that is 

BITSET(65520) = {4 .. 15}

or 

BITSET(65520) = {0 .. 11}

for a 16-bit architecture.

literature

Individual evidence

  1. ↑ ISO / IEC 10514-1: 1996
  2. ^ A Brief History of Modula and Lilith . In: Advances in Modular Languages ​​- Proceedings of the Joint Modular Languages ​​Conference , Ulm 1994