Scor­pio News

In Modula 2 the definition has been left quite vague. The implementer has to provide certain modules such as system, texts, in/out, files etc., but the exact definition of what these modules contain has been left open. Never the less the spirit of the language is that there should be no code that could not be wrtten by a user of the language.

Here Borland have infringed on this suggestion, in providing procedures write and writeln which can have a variable number of parameters, i.e. they are like the Pascal equivalents, but in the same way as Turbo Pascal has become the de facto standard for pascal, as it provided users with the extensions they wanted, Turbo Modula 2 may also become a de facto standard for the same reasons.

In the Borland implementation of the language the following simple types are available:

In Modula 2 as with Pascal it is possible to define any datatype that can be constructed from simple types. Also in most versions of Modula 2 is the System module, or to be more correct pseudo-module, in which version dependent code is located and the dirty tricks definitions are included. In this version the types Byte, Word, Address and Process are defined, the first three are obvious, I hope, but the last is a facility for allowing concurrent processes to occur allowing transfer of information between processes. An analogy in another high level language is hard to think of, the use of system common, or shared EMA in Fortran is similar but much more limited. To achieve a similar effect in Fortran usually involves direct operating system calls.

In this version of Modula 2, you can supply modules written in Microsoft Macro 80 compatible code, (as .REL files), which can be linked into main code once the appropriate definition module has been written. The Turbo environment is a particularly friendly environment to work in, you can set various options when compiling, for example you can turn the extensions to the standard off, you can make the compiler ignore case, in standard identifiers (such as END). Range and maths checks can be switched on or off, but the usual comments about wearing a lifebelt on load and taking it off when you go to sea apply in these cases and a listing of compilation can be obtained.

An interesting feature of this compiler is that it may compile to interpreted code or to native code the choice m left up to the user. Usually code is compiled to the interpreted form, for testing and then compiled to native code when fully debugged, but sometimes for compactness of code, it will be left as interpreted code. There are some bugs in the compiler in this area, I have had interpreted code work and native code then produced and turn its toes up.

The linker can produce either a .COM file, of can link together interpreted modules to reduce disk search time. The linker can be controlled in much the same way as linkers on super-minis and main frames, allowing direct formation of overlays and control of initialisation. Remember in Modula 2, each module may have a main as well as procedures.

The librarian is also an essential item of any Modula 2 system and the Turbo one is easy to use, quite like LU in its behaviour.

The shell is particularly friendly, allowing access to the editor, compiler linker and librarian, without leaving its environment. Particularly useful to hard disk users is the ease of moving from one user area to another and the ability to produce a directory list across the disk including all user areas. Access to file management utilities such as rename, copy, and delete are also provided.

The FTL Modula 2 (MSDOS version) comes with two manuals, one of 90 pages explaining the compiler in relation to the MSDOS operating system, and the second (of 105 pages) describing the language. It would not be possible to learn the language from these manuals alone, they do not claim to teach the language and should not be expected to do so. The manual contains some examples of code but these tend to be notes describing features rather than full program code.