The key features of Modula-3 programming

Support de cours The key features of Modula-3 programming, tutoriel & guide de travaux pratiques en pdf.

Evaluation

These examples should have given a the general avour of ML, but what is its real r^ole? It certainly meets all the criteria for an initial teaching language, but it has much broader uses than that. ML has been widely used for research work on theorem proving and, in particular, for work on formal veri cation of hardware and software. This is now moving into industrial projects and full commercially supported implementations are available on small PCs as well as professional work-stations, although development environments are still rather limited.
The core of the language is very simple and can be de ned in just a few pages; however, it is also quite appropriate to use it for large projects. Its mathematical basis gives it great coherence and uniformity. The strong type checking and ab-stract data types shown in the examples are obviously of value in large systems and ML also supports a mechanism for hiding internal information in packages, revealing only a chosen set of de nitions through a signature. This facilitates the orderly con-struction and maintenance of large systems consisting of many, separately compiled les of code.
The language lends itself to formal speci cation and analysis, but is not so well suited for some applications. For example, commercial data processing does not t well with a functional style of programming (although spreadsheets have been written in ML).
Although this was deliberately omitted from the examples above, it is possible to de ne mutable variables and for functions to have side e ects, but these are not comfortable within the language. Garbage collection and an interpreted implemen-tation are not obviously suitable for real-time systems either, although there are now compilers generating e cient code and modern garabage collectors are not as disruptive as their predecessors.

Modula-3

Modula-3 is descended from Pascal [21, 8] via Mesa [12], Cedar [9], Modula-2 [22, 23] and Modula-2+ [17]. It is de ned in Greg Nelson’s book [14], which also gives a rationale for the language design and gives examples of its novel features in use. There is an introductory textbook [5] and a version of Robert Sedgewick’s book on algorithms using Modula-3 [18].
The langauge’s design goals are encapsulated in the preface to the Modula-3 report [3]:
The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system.
Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+.
It also resembles its cousins Object Pascal, Oberon, and Euclid.
Modula-3 retains one of Modula-2’s most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features.

The key features of Modula-3 are

Interfaces: An explicit interface reveals only the public declarations in a module, while allowing other parts of it to be kept private. Each module imports the interfaces which it requries and exports the interfaces that it implements. The interface can be thought of as a contract between the supplier and client of a library module, specifying (amongst other things) the signatures of its pro-cedures, while deferring until later the exact nature of their implementation. They form a natural part of the design documentation of a large program.
Objects: An object is an abstract data type de ned in terms of the operations or methods permitted on it. A new object type can be de ned as a subtype of an existing type, in which case it inherits all the methods of the parent type while possibly adding new methods. It can also override the existing methods with alternative implementations having the same signature. (It is also possible to mask an inherited method by a new method with the same name but a di erent signature, but the obscured method can still be invoked.)
Objects and interfaces are combined in Modula-3 to provide partially opaque types, where some of an object’s elds are visible in a scope while others are hidden.
Generics: Modula-3 does not provide the full polymorphism of ML, but does allow a module (both interface and implementation) to be parameterised by another module. The generic module acts as a template in which some of the imported interfaces are regarded as formal parameters, bound to actual interfaces when the generic is instantiated. This is e ectively a textual operation, undertaken at compilation time.
Threads: Dividing a computation into concurrent processes (or threads of con-trol) is a fundamental method of separating concerns. In particular, any program dealing with external activities { ling system, communications net-work, human users and so on { should not suspend its dealing with all of them while waiting for just one to respond. Separating the program’s activities into separate threads which can block individually without a ecting the others’ execution makes this simpler to deal with.
Safety: Many of the problems with low-level langauges such as C arise through accidental corruption of a program’s code or data after using an invalid ar-ray index or performing incorrect address arithmetic. Such programs can be protected (at least from eachother) by placing them in separate address spaces, but this may limit performance. It is better to check for incorrect behaviour and handle it gracefully, rather than allow the program to continue unpredictably.
Garbage collection: A particular unsafe run-time error is to free a data structure still referred to by dangling pointers. Alternatively, storage leaks caused by failure to free unreachable structures cause an executing program’s data to grow without bound. Both of these problems can be resolved by tracing references and recovering redundant space by automatic garbage collection.
Exceptions: Another class of unsafe error arises when procedures report errors by returning special values, which are too easily left unchecked by the program-mer. Exceptions allow such out-of-band results to be returned and checked with very low overhead in the normal, error-free case, while making the be-haviour clear in the abnormal case.
Type system: Modula-3 is strongly typed and particular attention has been paid to making the type system uniform. In particular, a sub-type relation is de-ned and used to specify assignment compatibility and inheritance rules; the type of every expression can be determined from its constituents indepen-dently of its use and there are no automatic type conversions.
Simplicity: C.A.R. Hoare has suggested that as a rule of thumb a language is too complicated if it can’t be described precisely and readably in 50 pages. The designers of Modula-3 elevated this to a design principle, which they only narrowly failed to achieve.
As with ML, the language will be illustrated by a number of examples and then discussed.

Big numbers

Again, arbitrarily large natural numbers will be stored as a list of digits to the base 10. However, in Modula-3 the list is constructed explicitly with pointers rather than being manipulated directly within the language as in ML.
The rst observation is that there is a lot more boiler-plate text wrapped round this program than is need for its equivalent in ML. First, there is a heading identi-fying the module; in fact this has the special name Main identifying it as the main program. Secondly, there are explicit IMPORT requests for separately compiled mod-ules used by this program. The de nitions in the corresponding interfaces are made available in the ensuing scope. Thirdly, all the type information is explicit; every detail of the BigNum is speci ed as a pointer to a record with two elds. A small detail worth noting is that the elds can have default values, initialised whenever a record is allocated. In this case the tail pointer is set to default to NIL.
As noted above, the type of an expression is computed from its constituents. In this example, the type of the constant Base will be inferred to be an integer, and this tested for compatibility wherever it is used. This can often be done by the compiler, but may require a run-time check.
The bulk of the program is taken up with the de nition of four procedures which should be fairly self-explanatory. The NEW procedure allocates space on the heap, returning a pointer. Its rst argument is a reference type and any further arguments specify initial values for elds in the record referred to. The third argument to the Add procedure has a default value of 0; this avoids the need for the auxiliary doadd function used in the ML equivalent above. Otherwise, the procedure is roughly equivalent to the ML, eccept that the pattern matching of arguments is replaced by explicit testing. Conversions between big numbers and Modula-3’s built-in TEXT type make use of utility routines in the standard Char and Text interfaces.
Finally, the body of the module creates a big number with value 1 and adds it to itself repeatedly, printing out values from 21 to 2100. Incidentally, the repeated assignment to the variable bi and the various manipulations of the TEXT type will result in the generation of large amounts of unreachable heap storage which will be recovered by the garbage collector.

……..