Modula-2
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:
- there are no devices for concurrent programming
- the division of a large program into numerous modules with clearly defined interfaces according to the teachings of software technology is not possible.
The new language, which was named "Modula", therefore contained two new concepts compared to Pascal (in addition to several changes in the syntax ):
- Procedures
NEWPROCESS
,TRANSFER
andIOTRANSFER
for handling concurrent processes ( threads ) in terms of cooperative multitasking and - that
MODULE
as a unit for the separate translation of program parts.
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 MODULE
instead of PROGRAM
as in Pascal. All parts compiled separately from the main program must be split into two files: One DEFINITION MODULE
only 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 MODULE
then 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 InOut
for input / output and MathLib
for 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 CARDINAL
for the non-negative numbers between 0 and 65,535. Mixed expressions containing both INTEGER
- and - CARDINAL
partial 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.535
applies.
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 FUNCTION
does not exist in Modula-2)
PROCEDURE myProcedure (f: myFunction; n: INTEGER): REAL;
the compiler will determine with each call of myProcedure
whether the currently f
transferred 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 ARRAY
s and RECORD
s.
Control structures
To avoid numerous BEGIN
- END
brackets in Modula-2, the IF
and WHILE
instructions are each terminated with a END
. GOTO
There 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 WORD
for a non-specific memory word and ADDRESS
for a memory address could be imported, as well as a function ADR
for determining the memory address of a construct and TSIZE
for 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:
- Megamax Modula-2 - ATARI ST (e) ( M68K )
- Hänisch Modula-2 - ATARI ST / TT (M68K)
- Aglet Modula-2 - AmigaOS ( PPC )
- GNU Modula-2 - GNU compiler collection (GCC)
- Objective Modula-2 - Cocoa and GNUstep support
- MOCKA Modula-2 Compiler System - BSD and Linux for x86
- XDS Modula-2 - Windows and Linux
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 M
the exported identifiers by so-called qualified identifiers , such as M.A
, M.B
available. Alternatively, Modula-2 knows the qualifying import
FROM M IMPORT A,B;
With this import the identifiers are then simply available in the form A
or B
; the origin from the module M
is 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
, gelb
and are also gruen
imported, 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
- Niklaus Wirth : Programming in Modula-2. 4th edition. Springer, Berlin a. a. 1988, ISBN 0-387-50150-9 .