Coronado Enterprises Modula-2 TUTOR

March 16, 1987

(Note: this file was converted to HTML format by Nacho Cabanes
( )
in October, 1999. No additional text nor any other modification)

(Generic Version)

This documentation and the accompanying software,
including all of the example programs and text files, are
protected under United States Copyright law to protect them
from unauthorized commercialization. This entire tutorial
is distributed under the "Freeware" concept which means that
you are not required to pay for it. You are permitted to
copy the disks in their entirety and pass them on to a
friend or acquaintance. In fact, you are encouraged to do
so. You are permitted to charge a small fee to cover the
mechanical costs of duplication, but the software itself
must be distributed free of charge, and in its entirety.

If you find the tutorial and the accompanying example
programs useful, you may, if you desire, pay a small fee to
the author to help compensate him for his time and expense
in writing it. A payment of $10.00 is suggested as
reasonable and sufficient. If you don't feel the tutorial
was worth this amount, please do not make any payment, but
feel free to send in the questionnaire anyway.

Whether or not you send any payment, feel free to write
to Coronado Enterprises and ask for the latest list of
available tutorials and a list of the known Public Domain
libraries that can supply you with this software for the
price of copying. Please enclose a self addressed stamped
envelope, business size preferred, for a copy of the latest
information. See the accompanying "READ.ME" file on the
disk for more information.

I have no facilities for telephone support of this
tutorial and have no plans to institute such. If you find
any problems, or if you have any suggestions, please write
to me at the address below.

Gordon Dodrill - March 16, 1987

Copyright (c) 1987, Coronado Enterprises

Coronado Enterprises
12501 Coronado Ave NE
Albuquerque, New Mexico 87122

Introduction to the Modula-2 Tutorial

Welcome to the programming language Modula-2, a very complete, high level language with many advanced features. Modula-2 was designed by Niklaus Wirth, the designer of Pascal. Based on experience with Pascal, Modula-2 was designed to make up for many of the deficiencies noted by programmers worldwide, and the changes make it a very powerful language with few limitations. In spite of its power, Modula-2 retains the simplicity of Pascal and can be used for small applications as easy as Pascal could be used.


Even though there are many similarities between the two languages, the differences are significant. This tutorial was written considering both the similarities and the differences between the languages. The first part of this tutorial is composed of those features that are common to Pascal and Modula-2 and are also of a fundamental nature. You will need to study all of Part I in order to write meaningful Modula-2 programs. If you are already a fairly experienced Pascal programmer, you will absorb this material very fast. Be sure to go through it all at least once because there are many small differences between the languages that you must consider.


The topics taught in Part II of this tutorial are those advanced features that are also available in Pascal. Some of these topics are pointers, dynamic allocation, records, and linked lists. They are very powerful tools that can be used to great advantage but are quite often overlooked by many Pascal programmers that I have talked to. These are the tools that give Pascal and Modula-2 an advantage in flexibility over such languages as BASIC and FORTRAN. They do require a bit of deep concentration to understand, but you will be greatly rewarded if you take the time to understand and use them.


Part III of this tutorial covers those aspects of Modula-2 that are not included in Pascal in any way. Some of the topics are independent compilation, the entire topic of modules, and concurrent processing. These are advanced topics and some of these topics may be the reasons that you selected Modula-2 as a programming language. The material covered in Part I in conjunction with that covered in Part III can lead to some very powerful programming techniques. To efficiently use this tutorial, you must carefully study all of the material in Part I, then you can do a lot of jumping around in Parts II and III and still cover the material in a meaningful manner. You may also choose to only study some chapters of the last two parts in order to learn the needed material for the programming problem at hand. I would like to emphasize that it is important that you cover the material in Part I very carefully and in order since so much depends on what was taught before. When you get to the last two parts, comments at the beginning of each chapter will tell you what parts need to be reviewed in order to effectively use the material in the chapter.


If you are a novice to computer programming, this course is for you because it is assumed that you know nothing about programming. Many sections, especially in the early chapters, will cover very basic topics for your benefit. The biggest problem you will have will be setting up your compiler for use, since this can be a very difficult task. Possibly you know someone with experience that would be willing to help you get started.


There are, at this time, a very limited number of Modula-2 compilers available, but it would not be possible to include notes on every compiler about how to install it for your computer. The COMPILER.DOC file on your distribution disk contains notes on all of the compilers we have had access to and some of the difficulties in setting them up for the IBM-PC or near compatibles. In addition, all compilers do not implement all functions defined in Niklaus Wirth's definition of the language. As many of these as we have found are listed in the same file. Finally, all of the problems in compiling the files on this disk are noted in the COMPILER.DOC file. It would be worth your effort to print out this file and keep the hardcopy handy while you are working your way through the lessons.

Modula-2, as defined by Niklaus Wirth, contains no provisions for input or output because they are so hardware dependent. It is up to each compiler writer to provide you with supplemental procedures for handling I/O (input/output) and a few other machine dependent features. Niklaus Wirth did recommend a library of I/O routines that should be available and most compilers contain at least those facilities, and usually provide many more. The COMPILER.DOC file will contain notes about differences in these facilities for those compilers which we have access to. The COMPILER.DOC file will be updated anytime new information is available.


All of the instructional programs are purposely kept simple and small to illustrate the point intended. It is of little value to you to present you with a large complex program to illustrate what can be illustrated in a small program better. In addition, every program is complete, and can be compiled and run. Program fragments frequently pose as many questions as they answer.

Because it would be a disservice to you to teach you a lot of simple techniques and never show you how they go together in a significant program, chapters 9 and 16 contain several larger example programs. A relatively small amount of description is given about these programs because you will have already covered the details and only need a quick overview of how to put the various constructs together. You will find some of these programs useful and will have the ability to modify and enhance them for your use since you have the source code.


I have seen example programs with the same name everywhere, and had a hard time deciding what names were required and what could be changed to something more meaningful. For example a "SORT" program is in a file named "SORT", the program name is "SORT", the input file is named "SORT", and variables were named "SORT1", SORT2", etc. This was no help to myself, a novice sorter, and would be no help to you. For that reason the first program is in a file named "PUPPYDOG.MOD" and the module name is "PuppyDog". It should be obvious to even the newest programmer that the name of a module can be anything if it is allowed to be "PuppyDog". You will learn later that well selected names can be a great aid in understanding a program. This will be evident in some of the early programs when variable names are chosen to indicate what type of variable they are.

Some compilers require that the module name be the same as the file name, and all require them to agree when you get to global modules because of the way "Type checking" is accomplished. It would be best for you to get into the habit of naming them both the same now. For that reason, all of the example programs use the same name for the file name and for the module name. Your compiler may allow you to use different names. It will be left up to you to study your manual and see if this is so for your compiler.


There are two primary methods used in running any computer program that is written in a readable form of English. The first method is an interpreter. An interpreter is a program that looks at each line of the "english" program, decides what the "english" on that line means, and does what it says to do. If one of the lines is executed repeatedly, it must be scanned and analyzed each time, greatly slowing down the solution of the problem at hand.

A compiler on the other hand, is a program that looks at each statement one time and converts it into a code that the computer understands directly. When the compiled program is actually run, the computer does not have to figure out what each statement means, it is already in a form the computer can run directly, hence a much faster execution of the program. Due to the nature of Modula-2, there will be few, if any, interpreters.


The programming exercises at the end of each chapter are a very important part of the tutorial. If you do them, you will embed the principles taught in each chapter more firmly in your mind than if you ignore them. If you choose to ignore them, you will be somewhat adept at reading Modula-2 programs but very ineffectual at writing them. By doing the exercises, you will also gain considerable experience in using your editor and compiler.

It will be assumed that you know how to use your compiler and that you have some kind of an editor for use with the example files. With the above in mind, you are now ready to begin your tour of Modula-2.

A sample program is included in this chapter for you to try with your compiler. It is left as an exercise for you to compile and run FIRSTEX.MOD. When you can successfully compile and run this program, you are ready to begin the tutorial on Modula-2 programming. Do not worry about what the statements mean in FIRSTEX.MOD, you will have a complete understanding of this program by the time you complete chapter 4.


FROM InOut IMPORT WriteLn, WriteString, WriteCard;



   WriteString("This is our first example program");
   FOR Index := 1 TO 12 DO
      WriteString("The value of the index is now ");

END FirstEx.

Chapter 1 – What is a computer program?

If you are a complete novice to computers, you will find the information in this chapter useful. If you have some experience in computer use, and especially programming, you can completely ignore this chapter. It will deal with a few of the most fundamental topics of computers and will have nothing to do with the Modula-2 programming language.


A computer is nothing but a very dumb machine that has the ability to perform mathematical operations very rapidly and very accurately, but it can do nothing without the aid of a program written by a human being. Moreover, if the human being writes a program that turns good data into garbage, the computer will very obediently, and very rapidly turn good data into garbage. It is possible to write a large program with one small error that will do just that. In some cases the error will be obvious, but if the error is subtle, the answers may appear to be right, and the error will go unnoticed. It is up to you, the human programmer, to write a correct program to tell the computer what to do. You can think of the computer as your very obedient slave ready to do your every whim. It is up to you to tell your slave what you want it to do.

A computer program is a "recipe" which the computer will use on the input data to derive the desired output data. It is similar to the recipe for baking a cake. The input data is comparable to the ingredients, including the heat supplied by the oven. The program is comparable to the recipe instructions to mix, stir, wait, heat, cool, and all other possible operations on the ingredients. The output of the computer program can be compared to the final cake sitting on the counter ready to be cut and served. A computer then is composed of two parts, the data upon which the program operates, and the data. The data and program are inseparable as implied by the last sentence.


Nearly any computer program requires some numbers that never change throughout the program. They can be defined once and used as often as needed during the operation of the program. To return to the recipe analogy, once you have defined how big a tablespoon is, you can use the same tablespoon without regard to what you are measuring with it. When writing a computer program, you can define the value of PI = 3.141592, and continue to use it wherever it makes sense knowing that it is available, and correct.


In addition to constants, nearly any computer program uses some numbers that change in value throughout the program. They can be defined as variables, then changed to any values that make sense to the proper operation of the program. An example would be the number of eggs in the above recipe. If a single layer of cake required 2 eggs, then a triple layer cake would require 6 eggs. The number of eggs would therefore be a variable.


All constants and variables have a name and a value. In the last example, the name of the variable was "eggs", and the value was either 2 or 6 depending on when we looked at the stored value. In a computer program the constants and variables are given names in much the same manner, after which they can store any value within the defined range. Any computer language has a means by which constants and variables can be first named, then assigned a value. The means of doing this in Modula-2 will be given throughout the remainder of this tutorial.


Some computer languages allow the programmer to define constants and variables in a very haphazard manner and then combine data in an even more haphazard manner. For example, if you added the number of eggs, in the above recipe, to the number of cups of flour, you would arrive at a valid mathematical addition, but a totally meaningless number. Some programming languages would allow you to do just such an addition and obediently print out the meaningless answer. Since Modula-2 requires you to set up your constants and variables in a very precise manner, the possibility of such a meaningless answer in minimized. A well written Modula-2 program has many cross checks to minimize the possibility of a completely scrambled and meaningless output.

Notice however, in the last statement, that a "well written" Modula-2 program was under discussion. It is still up to the programmer to define the data structure in such a way that the program can prevent garbage generation. In the end, the program will be no better than the analysis that went into the program design.

If you are a novice programmer, do not be intimidated by any of the above statements. Modula-2 is a well designed

tool that has been used successfully by many computer novices and professionals. With these few warnings, you are ready to begin.

Chapter 2 – Getting started in Modula-2


We are ready to look at our first instructional program in Modula-2. Assuming that you have a full screen editor of some type, load the program PUPPYDOG.MOD and display it on your screen. It is an example of the minimum Modula-2 program. There is nothing that can be left out of this program and still have a compileable, executable program.

MODULE PuppyDog;


END PuppyDog.

The first word in the program, "MODULE", is the name that identifies a module, and it must be written as given here, in all capital letters. During the entire first part of this tutorial, we will use only this type of a module. There are other types but we will not look at any of them until we get to part III of this tutorial. Modula-2 requires us to name our module so we give it a name, "PuppyDog". We could have used any name that qualifies as an identifier but we have chosen a name that has nothing to do with computers as an illustration that any name could be used. In a practical program, you would probably use a name that was descriptive of the program in some way.


An identifier is a combination of letters and numbers that Modula-2 uses to identify a variable, program name, procedure name, and several other quantities. In Modula-2, an identifier is composed of any number of characters. The characters may be any mix of alphabetic and numeric characters, but the first character must be an alphabetic character. The case of the alphabetic character is significant such that "IdentNumber1", "IDENTNUMBER1", and "IdEnTnUmBeR1" are all different identifiers. No spaces or any other special characters are allowed.


The "header" line is terminated with a semicolon according to the formal definition of Modula-2. A semicolon is a statement separator and many will be used in large programs. Following the semicolon, we come to the program itself. The program statements are enclosed between the two words "BEGIN" and "END". In this case there are no statements, but if there were some, they would be placed between the two indicated words. Finally, the module name is repeated after the "END" and it is followed by a period. The module name is repeated in order to make the program easier to understand by clearly marking its limits. In this case it really doesn't add to the clarity of the program, but in a large program it can be of significant help. The period marks the end of the listing and can be thought of as the period that marks the end of a sentence.

The three words, MODULE, BEGIN, and END, are special words in Modula-2. They are "reserved words" because they are used for a specific purpose and cannot be used for any other purpose. They are not available for your use in any way except for the defined purpose. The reserved words in Modula-2 are always capitalized or the compiler will not consider them as reserved words. Remember that alphabetic characters must have the correct case in Modula-2. Some other languages, most notably Pascal, allow you to use either case anywhere and it converts them internally so that they are the same. It would be permissible for you to use words such as "Begin" or "End" as variables in a Modula-2 program, but it would be very poor programming practice and should be avoided. We will come across many other reserved words in these lessons. There are 40 reserved words in Modula-2.

You should have learned how to use your compiler by now so you can compile and run this program. It will do nothing, but that is significant in itself, because it should at least return to the operating system after it finishes doing nothing. That may sound a little silly, but it does take a considerable amount of effort to load, transfer control to the program, and set up linkage back to your Disk Operating System.

It should be noted at this time that the Modula-2 compiler doesn't care about extra blanks or linefeeds and the careful programmer will insert extra blanks and linefeeds as desired in order to make the program easier to read. As you continue to program in Modula-2, you will no doubt develop a style of your own and hopefully your programs can be read easily by other programmers.


Load and display the program named WRITESM.MOD for an example of a Modula-2 program that does something. First you should notice that the elements of the first program are still here as they will be in every Modula-2 program. The same three reserved words are used here as before, but now there are some added statements.


FROM InOut IMPORT WriteLn, WriteString;


   WriteString("This line will be displayed on the monitor.");
   WriteString('This line will be displayed too.');
   WriteString("This will all be ");
   WriteString('on one line.');
   WriteString('She said, "I ');
   WriteString("don't ");
   WriteString('like dogs."');

END WriteSm.

The line near the beginning that begins with the reserved word "FROM" is a special line that must be used in any program that accesses external procedures. We will not try to define this line at this time. We will only say that every external call in Modula-2 requires a definition of where to find the procedure. The module named "InOut" is a collection of input and output routines that are available for our use and this line in the program tells the system to look in the "InOut" collection for the procedures named "WriteLn" and WriteString". When the program needs these particular functions to do what we ask it to do, it knows where to find them. We will cover the IMPORT list in detail later in this tutorial. Until then, simply use the example programs as a guide when you wish to write a practice program.


Between the BEGIN and END statements, which we defined previously as the place where the actual program is placed, we have a series of "WriteString" and WriteLn" statements. These statements are almost self explanatory, but we will say a few words about them anyway. Each line is a call to a "procedure" which is a very important feature of Modula-2. A "procedure" is an external servant that does a certain job for us in a well defined way. In the case of the "WriteString", it looks at the string of characters supplied to it and displays the string of characters on the monitor at the current cursor position. In the case of the "WriteLn" procedure, it serves us by moving the cursor down one line on the monitor and moving it to the left side of the screen.

The parentheses are required for the WriteString because it has data following it. The data within the parentheses is data supplied to our slave or helper. It gets the string of characters between the quotation marks or the apostrophes and displays the string on the monitor. You have a choice of delimiters so that you can output the delimiters themselves. If you desire to output a quotation mark to the monitor, use apostrophes for delimiters, and if you wish to output apostrophes, use quotation marks. If you wish to output both, break the line up and output it piecemeal as in the last example line.

This program should be very clear to you by now. First we tell the system where to get the procedures, then we list the procedures in the order required to produce the desired results. It should be apparent that the lines of the program between the reserved words BEGIN and END are simply executed in order. Compile and run the program and observe the output on your monitor. It should be mentioned at this point that it is possible to redirect the output to the printer or to a disk file but we will not be doing that for quite some time. We will stay with the basic syntax of Modula-2 for now.


No program is complete without a few comments embedded in the program as notes to the programmer describing the reasons for doing some particular thing. The notes are particularly helpful to another programmer who needs to modify the program some day. It is not necessary for the computer to understand the notes and in fact, you don't want the computer to try to understand the notes, so you tell the compiler to ignore the notes completely. How to do this is the object of our next program named MODCOMS.MOD which you should load and display on your monitor.

(* This is a comment that is prior to the start of the
   program itself. *)


FROM InOut IMPORT WriteLn, WriteString;

                     (* This is a block
                        of comments that
                        illustrate one way
                        to format some of
                        your comments.    *)

BEGIN  (* This is the beginning of the main program *)

   WriteString("This is a comments demo program.");
(* WriteString("This will not be output.");
   WriteString("Nor will this."); *)

END ModComs.  (* This is the end of the main program *)

(* This is a comment after the end of the program *)

In Modula-2, comments are enclosed in pairs of double characters. The comment is started with the "(*", and ended with the "*)". The program on your monitor has several examples of comments in it. If the comments were completely removed, the program would be very similar to the last one but a lot shorter. Notice that comments can go nearly anywhere in a program, even before the header statement or after the ending period. Comments can be used to remove a section of program from consideration by the compiler so that a particularly troublesome section of code can be "commented out" until you solve some of the other problems in program debugging. It is important to remember that comments can be "nested" in Modula-2 so that a section of code can be "commented out" even if it contains other comments.

This particular program is not meant to be an example of good commenting. It is really a sloppy looking program that would need some work to put it into a good style, but it does illustrate where it is possible to put comments.


Load and display the program named GOODFORM.MOD for an example of a well formatted program. Since Modula-2 allows you to use extra spaces and blank lines freely, you should use them in any way you can to make your programs easy to understand, and therefore easy to debug and modify. Special care has been given to style in this program and it payed off in a very easy to understand program. Even with your very limited knowledge of Modula-2 programming you can very quickly decipher what it does. It is so well formatted that comments are not needed and they would probably detract from its readability. No further comment is needed or will be given. Compile and run this program to see if it does what you think it will do.

MODULE GoodForm;

FROM InOut IMPORT WriteLn, WriteString;


   WriteString("Programming style ");
   WriteString                  ("is a matter of ");
   WriteString                                 ("personal choice.");
   WriteString("Each person ");
   WriteString            ("can choose ");
   WriteString                       ("his own style.");
   WriteString("He can be ");
   WriteString          ("very clear, or extremely messy.");

END GoodForm.


Load and display UGLYFORM.MOD for an excellent example of bad formatting. If you can see at a glance what this program does you deserve the Nobel Prize for understanding software if such a thing exists. The syntax for this program follows all of the rules of Modula-2 programming except for good style. Without saying anything else about this mess, I would suggest that you try to compile and run it. You may be surprised to find that it does compile and run, and in fact it is identical to the last program. Keep in mind that you can add extra blanks and linefeeds anyplace you desire in a program to improve its readability.

IMPORT WriteLn, WriteString;BEGIN
WriteString("Programming style ");WriteString("is a matter of ");
WriteString("personal choice.")                ;WriteLn;WriteString
("Each person ")
("can choose ");
("his own style.");WriteLn;WriteString("He can be ");WriteString
("very clear, or extremely messy.")
;WriteLn;END UglyForm

Hopefully, the last two programs will be an indication to you that good programming style is important and can be a tremendous aid in understanding what a program is supposed to do. You will develop your own programming style as time goes by. It is good for you to spend some effort in making your program look good, but don't get too excited about it yet. Initially, you should expend your effort in learning how to program in Modula-2 with reasonable style and strive to improve your style as you go along. It would be good for now if you simply tried to copy the style given in these lessons.


1. Write a program that will display your name on the monitor.

2. Write a program that will display your name on the monitor along with your address, city and state in 3 separate lines.

3. Add a comment to the MODCOMS.MOD file between the words "IMPORT" and "WriteLn" to see if the compiler will allow you to put a comment within a statement.

Chapter 3 – The simple Modula-2 data types.

The material in this chapter is extremely important to you as you strive to become a good Modula-2 programmer, but you may also find it to be somewhat tedious because it contains so many facts. This material is needed in order to develop the topics in the next few chapters, but all of the details are not necessarily required. For that reason, you may wish to go through it rather rapidly picking up the high points and come back to this chapter for the details later when they will be much more meaningful. Do not completely pass over this material at this time or the next few chapters will be meaningless unless you are already highly experienced in other programming languages.


Load and display the program named INTVAR.MOD for our first program with some variables in it. This program begins in the usual way since it has a MODULE header and the IMPORT list. Next we come to a new reserved word, VAR. This word is used to indicate to the compiler that we wish to define one or more variables. In Modula-2, there is a rule that says you can use nothing until it is defined. If we wish to use a variable in the program, we must first define that it will exist, and what kind of a variable it is. After that, it can be used in the program to do what needs to be done.

(* Chapter 3 - Program 1 *)

FROM InOut IMPORT WriteLn, WriteString, WriteInt;

VAR Count : INTEGER;  (* The sum of two variables *)
    x,y   : INTEGER;  (* The two variables to add *)


   x := 12;
   y := 13;
   Count := x + y;

          (* Assignments complete, now display the results *)

   WriteString("The value of x  =");
   WriteString("The value of y  =");
   WriteString("The sum of them =");

   x := 0FFH;   (* This is the way to assign a hexadecimal number *)
   y := 177B;   (* This is the way to assign an octal number      *)

END IntVar.

Following the reserved word VAR, we have the variable named "Count" defined. The reserved word INTEGER following the colon states that the variable "Count" will be of type INTEGER. This means that it can store any whole number between -32768 to 32767. Don't worry too much about this yet, the next program will completely define what an INTEGER type variable is. It is important to recognize that after we have defined the variable "Count", it still doesn't have a value stored in it, that will come later.

The next line has two more variables defined, namely "x", and "y". They are also INTEGER type variables and do not have a value stored in them yet. You can think of the three variables as three empty boxes, each capable of storing a number but with no number in them yet. It would be perfectly permissible to put all three variables on one line, or to have separated them such that each was on a separate line. At this point, the program doesn't know that there is any difference between them, because there isn't any. The fact that one will contain the sum of the other two has no meaning yet, the comments are only for us, not the computer.


Now we will go to the program itself. The first line sets the variable "x" equal to 12, in effect putting the number 12 in the box mentioned earlier. The sign := is the Modula-2 symbol for assignment. It is most meaningful to read the symbol "gets the value of" since it is not really stating a mathematical equality but is saying in effect, "assign the value of this to the variable at the left." The entire line can be read as "x gets the value of 12." There is now a value assigned to the variable "x" declared in the header. The next statement assigns the value of 13 to the variable "y". Finally the value of the data stored in the variable "x" is added to the value of the data stored in the variable "y", and the sum is stored in the variable "Count". We have therefore done our first calculations in Modula-2 but we will do many more before this tutorial is completed.

Notice that each statement is terminated with a semicolon, a Modula-2 requirement.

The three variables are then displayed on the monitor with appropriate prose to identify them. The only new statement here is the "WriteInt" procedure that needs a little explanation. This procedure is used to output an INTEGER type variable to the monitor or whatever device is being used. By definition, it contains two quantities within the parentheses, the variable name and the number of columns it should fill. If there are not enough columns to output the data, more will be used so that no digits will be truncated. If all are not needed, leading blanks will be output. If the variable "x" had the value of 1234 when we came to program line 18, all four digits would be output in spite of the request for three. Since "x" has the value of 12, only two columns will be used and one leading blank will be output. In like manner, "y" is allotted 4 columns and "Count" is to be output in 6 columns.

The last two lines of the program assign new values to two of the variables. The variable "x" is assigned the value of FF hexadecimal which is 256 decimal, and "y" is assigned the value of 177 octal which is 127 decimal. This is only done as an illustration to you of how it is done. If you don't understand these two numbering systems, simply ignore this until you have a need for it.

Compile and run this program to see if it does what you expect it to do. The important thing to notice in this program is the variable definition in the definition part of the module and the variable assignment in the program part. It should be obvious, but it would be well to mention that

the definition part of the module extends from the module name to the reserved word "BEGIN" and is where all definitions are put. Likewise, the program part of the module includes all statements from the "BEGIN" to the "END".


Modula-2 has several predefined data types that you can use in your programs. You also have the ability to define any number of complex types built up from the simple types but we will not discuss this until we get to chapter 6 and beyond. The simple types are INTEGER, CARDINAL, REAL, BOOLEAN, and CHAR. Each has its own purpose and its own peculiarities and we will cover each type one at a time.


Load and display the program named INTMATH.MOD for an example of INTEGER math. In the declaration part of the program (the part prior to the BEGIN) we have 7 INTEGER type variables defined for use in the program. We will use them to illustrate INTEGER arithmetic.

(* Chapter 3 - Program 2 *)

FROM InOut IMPORT WriteLn, WriteString, WriteInt;

VAR IntSum, IntDif, IntMul, IntDiv, IntRem : INTEGER;
    A, B                                   : INTEGER;

   A := 9;             (* Simple assignment                  *)
   B := A + 4;         (* Addition                           *)
   IntSum := A + B;    (* Addition                           *)
   IntDif := A - B;    (* Subtraction                        *)
   IntMul := A * B;    (* Multiplication                     *)
   IntDiv := B DIV A;  (* Integer division, the result is a
                          truncated integer number.          *)
   IntRem := B MOD A;  (* d is the remainder of the integer
                          division.                          *)
   A := (A + B) DIV (3*B + 7);  (* Composite math statement  *)

   WriteString("The integer values are ");

   INC(A);       (* This increments the value of A   *)
   DEC(A);       (* This decrements the value of A   *)
   INC(A,3);     (* This adds 3 to the value of A    *)
   DEC(A,7);     (* This reduces the value of A by 7 *)
   INC(A,B*2+4); (* A composite incrementing amount  *)

   A := MIN(INTEGER);  (* This produces the smallest INTEGER *)
   B := MAX(INTEGER);  (* This produces the largest INTEGER  *)

END IntMath.

An INTEGER variable, by definition, can store any whole number between -32768 and 32767. An attempt to store any other value in an INTEGER type variable should produce an error by your compiler but it may produce some other result. Some compilers may store a -32769, which is one count too low, as a 32767 which is at the top end of the range. This is due to the two's complement arithmetic that you don't need to understand at this point. It will be left to you to determine what your compiler does in such a case.

The first line in the program is nothing new to you, it simply assigns the variable "A" the value of 9. The second line adds 4 to the value stored in the variable "A" and the result, 13, is stored in the variable "B". Next the values stored in the variables "A" and "B" are added together and the sum, which is 9 + 13, is stored in the variable "IntSum". Continuing in the same manner, the difference and the product are calculated and stored. When we come to INTEGER division, we are breaking new ground because the result is truncated to the largest whole number resulting from the division. Thus 13 DIV 9 results in 1 because the remainder is simply dropped. The next construct, B MOD A results in the remainder of the division, in this case 4. You will find these operations very useful as you progress as a Modula-2 programmer.

The intent of the next line is to illustrate that you can do several math operations in a statement if you are careful to put the parentheses in the proper places. There are definite rules about operator precedence but I recommend that you use lots of parentheses to remove all doubt as to what the results will be.

The results of the operations are displayed in 6 columns and we move on to several new operations. The first new operation is the "INC" which is short for "increment". This simply increments the variable contained within the parentheses and if a second argument is given, the variable is incremented by the value of that variable. In like manner the "DEC" procedure decrements the variable in the parentheses by one unless a second argument is given in which case the variable is decremented by the value of that variable.

It may not be clear at this point, but the second variable itself may be another variable name or even a composite of several as long as it results in an INTEGER type variable. This is illustrated in the program.

Finally, we come to the last two procedures in this program, the "MIN" and the "MAX". These two procedures will return the value of the smallest possible INTEGER, -32768 and the largest possible INTEGER, 32767. These are the values returned for a 16 bit microcomputer which is what you are probably using since that is what this tutorial is intended for. It would be well to add that not all Modula-2 compilers implement these functions so you may need to comment out these two lines in order to compile and run this program.

Compile and run this program and observe the output. If your compiler results in errors, you may have to make some changes in order to compile it. Refer to the COMPILER.DOC file on the distribution disk for notes on some of the more popular Modula-2 compilers.


Load and display the file named CARDMATH.MOD for an example of CARDINAL mathematics and output. In this file, 7 variables are defined as CARDINAL and one more as INTEGER. A CARDINAL variable can store any whole number from 0 to 65535 in a 16 bit microcomputer, although the range may be different if you are using an unusual computer or compiler.

(* Chapter 3 - Program 3 *)
MODULE CardMath;

FROM InOut IMPORT WriteLn, WriteString, WriteCard;

VAR CardSum, CardDif, CardMul, CardDiv : CARDINAL;
    A, B, CardRem                      : CARDINAL;
    IntVar                             : INTEGER;

   A := 9;              (* Simple assignment                  *)
   B := A + 4;          (* Addition                           *)
   CardSum := A + B;    (* Addition                           *)
   CardDif := B - A;    (* Subtraction                        *)
   CardMul := A * B;    (* Multiplication                     *)
   CardDiv := B DIV A;  (* Integer division, the result is a
                          truncated integer number.          *)
   CardRem := B MOD A;  (* d is the remainder of the integer
                          division.                          *)
   A := (A + B) DIV (3*B + 7);  (* Composite math statement  *)

   WriteString("The cardinal values are ");

   IntVar := A;       (* INTEGER and CARDINAL are assignment  *)
   B := IntVar + 27;  (* compatible, but cannot be mixed in   *)
                      (* any expression.                      *)

   A := 125;          (* CARDINAL assignment                  *)
   B := A - 112;      (* CARDINAL math                        *)
(* B := 125 + (-112);    Illegal CARDINAL Math - see text     *)

   IntVar := 125 + (-112);       (* INTEGER math, OK here     *)

   INC(A);      (* This increments the value of A       *)
   DEC(A);      (* This decrements the value of A       *)
   INC(A,4);    (* This adds 4 to the value of A        *)
   DEC(A,6);    (* THis subtracts 6 from the value of A *)

   A := MIN(CARDINAL);  (* This produces the minimum CARDINAL *)
   B := MAX(CARDINAL);  (* This produces the maximum CARDINAL *)

END CardMath.

The first few lines are the same as the last program so very little needs to be said about them except for the subtraction example. In this case, the result of the subtraction would be negative if it were carried out as in the last program so "A" is subtracted from "B". It is an error to attempt to store a negative number in a CARDINAL type variable. For that reason, a CARDINAL should not be used if there is any chance that it will be required to go negative. Programming experience will be the best teacher when it comes to deciding what variables to use in each situation.

In this program the variables are once again displayed, but now the procedure named "WriteCard" is used for output because the variables to output are CARDINAL.

The next two statements indicate that INTEGER and CARDINAL variables are "assignment compatible" meaning that they can be assigned to each other with the := operator. They cannot however, be mixed in calculations. Constants in an expression are assumed to be of the same type as the variables in the expression and they must agree. For that reason, the expression in line 36 is invalid because (-112) is required to be a CARDINAL constant but it is negative and therefore not CARDINAL. In the prior line it is permissible to subtract 112 from the value of "A" as long as the result is still positive. As an exercise, change line 34 such that a number less than 112 is assigned to "A". The program will compile without error but when you run it, you should get a runtime error because the CARDINAL assignment is out of range. Notice that the constant value of -112 is allright for use an an INTEGER variable.

The remaining statements in the program are the same as the last program so additional explanation is unneeded. It would be good to point out that in the case of CARDINAL, the "MIN" and "MAX" procedures will return values of 0 and 65535 for most 16 bit implementations.

Compile and run this program remembering that it may be necessary to comment out the "MIN" and "MAX" statements to get a successful compilation.


Load and display the program named REALMATH.MOD for a demonstration of the data type REAL. The definition part of this program is similar to the last with some additions to the IMPORT list. Your compiler may use different names for some of the procedures here, so if you get a compile error you will need to modify these. We will study the IMPORT (and EXPORT) list in detail later, so be patient.

(* Chapter 3 - Program 4 *)
MODULE RealMath;

FROM InOut IMPORT WriteString, WriteLn;
FROM RealInOut IMPORT WriteReal;
FROM MathLib0 IMPORT sin, cos; (* Your system may use a different
                                  name for either the module or the
                                  trig functions.                   *)

VAR Sum, Diff, Product, Div : REAL;
    A, B    : REAL;
    Inumber : INTEGER;
    Cnumber : CARDINAL;

   A := 3.234;                      (* Assigns a value          *)
   B := A + 1.0123;                 (* Add a constant           *)
   Sum := A + B;                    (* Add two variables        *)
   Product := A * B;                (* Multiplication           *)
   Div := A / B;                    (* Division                 *)
   Diff := A - B;                   (* Subtraction              *)
   A := (A + B)/(12.345 * A - B);   (* Multiple math expression *)
   B := sin(A)*cos(B);

   WriteString("The REAL values are");
   WriteString("  ");
   WriteString("  ");
   WriteString("  ");

         (* Conversion between data types - illustration  *)

   Inumber := 15;          (* This is an INTEGER              *)
   Cnumber := 333;         (* This is a CARDINAL              *)
   A := FLOAT(Inumber);    (* INTEGER to REAL                 *)
   B := FLOAT(Cnumber);    (* CARDINAL to REAL                *)
   Inumber := TRUNC(Sum);  (* REAL to INTEGER                 *)
   Cnumber := TRUNC(Sum);  (* REAL to CARDINAL                *)

   A := MIN(REAL);   (* This produces the smallest REAL *)
   A := MAX(REAL);   (* This produces the largest REAL  *)

END RealMath.

Several REAL variables and one each of the INTEGER and CARDINAL types are defined for use in the program. The REAL type variable can contain numbers in a wide range and with fractional parts included. The exact range, and the accuracy will vary widely depending on your implementation. It will be up to you to check your reference manual for the limits on your computer and compiler. A REAL type number is defined as one with a decimal point. The mathematics are the same as with the other two except that the division symbol is the slash (/). There is no "MOD" for REAL type numbers because there is theoretically no remainder, since a fractional part is computed as part of the calculation.

The four results are displayed on the monitor with 12 columns allowed for each result and two extra blanks displayed between each number. Unfortunately, we have no control over how many digits will be displayed following the decimal point. This would be nice for outputting data in a financial model where we would like to have two digits following the decimal point. When we get to the advanced part of this tutorial, we will write our own procedure for doing that in such a way that we can call it from any program just like we call these output procedures.


Beginning in line 37, we assign the INTEGER and CARDINAL variables some values and convert the values to type REAL by using the procedure "FLOAT". We then convert the variable "Sum" to INTEGER and CARDINAL by use of the procedure "TRUNC". The fractional part, if any, will simply be thrown away. These procedures will be very useful in many of your programs.

The last two lines return the value of the largest possible REAL number and the smallest REAL number for your implementation. Once again, your compiler may not support these two functions and they may have to be commented out in order to compile.

Compile and run this program.


Load and display the file named BOOLMATH.MOD on your monitor for an example of BOOLEAN variables. A BOOLEAN variable can only have one of two possible values, TRUE or FALSE. These variables cannot be printed directly but can be used to control other print statements to print out a representation of their value. We will see how later.

(* Chapter 3 - Program 5 *)
MODULE BoolMath;

VAR IsIt, WillIt, What : BOOLEAN;
    A, B, C            : INTEGER;


   A := 22;        (* Assign some values to work with *)
   B := 12;
   C := -12;

   IsIt := A = 22;     (* TRUE    - equal to                    *)
   IsIt := A = 23;     (* FALSE   - equal to                    *)
   WillIt := A > B;    (* TRUE    - greater than                *)
   WillIt := A < B;    (* FALSE   - less than                   *)
   What := WillIt;     (* FALSE   - assignment                  *)
   IsIt := B <= 12;    (* TRUE    - less than or equal          *)
   IsIt := B >= 4;     (* TRUE    - greater than or equal       *)
   IsIt := A # B;      (* FALSE   - not equal                   *)
   IsIt := A <> B;     (* TRUE    - not equal                   *)

   IsIt := TRUE;
   What := FALSE;
   WillIt := IsIt AND What;      (* FALSE because What is FALSE *)
   WillIt := IsIt AND NOT What;  (* TRUE                        *)
   WillIt := IsIt OR What;       (* TRUE because one is TRUE    *)
   WillIt := NOT IsIt OR What;   (* FALSE                       *)
   IsIt := (A = B) OR (B = C) OR (A = 22);
   IsIt := ((A < B) AND (B < C)) OR NOT (B > C);

   (* We have not studied a way to print out representations of *)
   (* BOOLEAN variables so it will have to wait.                *)

END BoolMath.

We define 3 BOOLEAN variables and 3 INTEGER variables and assign values to the 3 INTEGER variables in the program for use in these illustrations. In line 13 the BOOLEAN expression "A = 22" is TRUE, therefore the BOOLEAN variable "IsIt" is assigned the value TRUE. The variable "IsIt" could be used later in the program to make a decision, by a yet undefined method, to do something or bypass it. In like manner, the next statement assigns "IsIt" the value FALSE because A is not equal to 23. The remainder of the allowed BOOLEAN expressions are defined in the next few lines and are left for your inspection and study.

Beginning in line 25, composite BOOLEAN expressions are illustrated. As many BOOLEAN expressions as desired can be combined with AND and OR operators. If two or more BOOLEAN expressions are combined with the AND, the result is TRUE if all expressions are TRUE. If two or more BOOLEAN expressions are combined with the OR, the result is true if any of them are TRUE. The NOT operator inverts the sense of what it modifies, it turns a TRUE to FALSE and vice-versa. Finally a couple of composite BOOLEAN expressions are given for illustration of the amount of complexity that is allowed, although there is no real limit as to how far you can go with the complexity. Good programming practice would dictate that you keep it simple and understandable.


First it is important that you use the same type of variables within a BOOLEAN expression. REAL's can be compared to REAL's and INTEGER's to INTEGERs, but REAL's cannot be compared to INTEGER's. CARDINAL and CHAR types can also be compared to their own types, but none of the four can be compared directly to each other.

Secondly, Modula-2 uses a shortcut evaluation technique for BOOLEAN evaluation. Evaluation proceeds from left to right and if it finds a result which will positively determine the outcome, evaluation stops. For example, if it is evaluating a string of 5 comparisons all combined with an AND, and it finds that the second term is FALSE, evaluation stops there. Since all terms must be TRUE for the result to be TRUE, it makes no difference what values the last three are, the result will be FALSE because of the second term.


Load and display the program named CHARDEMO.MOD for an illustration of the last simple variable type, CHAR. Text data is stored in a computer in a format utilizing the CHAR data type. Although there are exceptions, such as when text is stored in some form of a packed mode, this is nearly always true. This tutorial was written with a word processor that uses a CHAR type for text storage, and few word processors use any other method.

(* Chapter 3 - Program 6 *)
MODULE CharDemo;

FROM InOut IMPORT WriteLn, Write, WriteString;

VAR Char1, Char2, Dog3, Cat4 : CHAR;
    Index                    : INTEGER;


   Char1 := 'A';                     (* This is a capitol A      *)
   Char2 := "T";                     (* This is a capitol T      *)
   Index := ORD(Char1) + 2;          (* The numerical value of A
                                        plus 2 = the value of C  *)
   Dog3 := CHR(Index);               (* The letter C             *)
   Cat4 := '"';                      (* The quotation mark       *)

   WriteString("The characters can spell ");
   Char1 := "S";                     (* Change to the letter S   *)

   Char1 := 65C;                       (* This sets Char1 to 'A' *)
   Char1 := 'a';                       (* This sets Char1 to 'a' *)
   Char2 := CAP(Char1);                (* This sets Char2 to 'A' *)

END CharDemo.

Although there are many different ways to store text, only two are used to any level of significance, EBCDIC and ASCII. ASCII is used almost exclusively in micro computers. I have never heard of an implementation that used EBCDIC in a microcomputer, so we will limit our discussion to ASCII. This merely refers to the way the characters of the alphabet and all other characters are represented in the computer. The ASCII standard defines that the value of 65 will be the letter 'A', 66 will be the letter 'B', etc. If everyone uses the same standard, transfer of data from one computer to another is greatly simplified.

The program named CHARDEMO has the usual header with 4 CHAR type variables defined for use in the program. An INTEGER is also defined. In the program itself, we begin by assigning 2 of the variables some CHAR data. Since a CHAR variable is capable of storing one letter, numeral, or special character, each variable is assigned one letter. The single or double quotes are used as an indication to the compiler that you intend for it to use the letter as a CHAR type variable rather than as another variable name. Of course if you wanted to use "A" as a variable name, you would have to define it in the definition part of the module.


The next instruction gets the ordinal value of the letter "A", adds two to it, and assigns that value to the variable "Index", which must be an INTEGER (although it could have been defined as a CARDINAL). Refer to the documentation that came with your computer and you will find an ASCII table that will define the letter "A" as 65. Finally, the CHAR type variable "Dog3" is assigned the character value of "Index". Your ASCII table should define 67 as the letter "C". It is important to understand that the CHAR variable "Dog3" contains the character representation of the letter "C", and the INTEGER variable "Index" contains the numerical value of the ASCII representation of the letter "C". It would be perfectly allright to use the variable "Index" for any desired numerical calculations, but not to display the letter "C". On the other hand, it would be allright to use the variable "Dog3" to display the letter "C" on the monitor but it could not be used for any calculations. The purpose therefore, of the two procedures "ORD" and "CHR", is to translate from one type to the other.

The variable "Cat4" is assigned the double quote by enclosing it in the single quotes, and the characters are output in a funny order to spell "CAT. The variable "Char1" is assigned the value "S", and the word is completed resulting in the full word "CATS" on the monitor after the program is compiled and run.

If this were the only way to use the CHAR type variable, it would be very tedious and frustrating, but there are other methods to use the CHAR type that are far more useful as you will see.

Next, an additional means of assigning a CHAR type variable is given. By assigning the CHAR variable "65C", it is the same as writing CHR(65), resulting in the variable having the internal value "A". A number less than 256 followed by a "C" is defined by Modula-2 as a CHAR type constant.

Finally, the variable "Char1" is assigned the letter "a" and it is converted to upper case "A" with the procedure CAP. This procedure will convert the argument to its upper case equivalent if it is a lower case letter. If its argument is an upper case letter or any other character, it will do nothing to it.

Compile and run this program and observe the output.


Load and display the file named TRANSFER.MOD for several examples of transferring data between the various simple data types. The transfer functions given here may not seem too important at this time, but some time spent here will help to reduce the frustration later when you get seemingly wrong errors that say you are using incompatible types in a statement. All of the program will not be discussed, only those statements that use some of the more unusual capabilities of Modula-2.

(* Chapter 3 - Program 7 *)
MODULE Transfer;

VAR Int1,  Int2  : INTEGER;
    Card1, Card2 : CARDINAL;
    Real1, Real2 : REAL;
    Char1, Char2 : CHAR;


   Int1  := 14;
   Int2  := 35;
   Card1 := Int1 + Int2 + 23;            (* assignment compatible *)
   Card2 := Card1 - 13 * 2 + CARDINAL(Int1);   (* mixed types     *)
   Card2 := Card1 - 13 * 2 + CARDINAL(Int1);   (* assignment comp *)
   Int1  := Int2 * INTEGER(Card1);

   Real1 := 12.0;
   Real2 := Real1 + FLOAT(Card2) * 1.112;     (* CARDINAL to REAL *)
   Real2 := Real2 + FLOAT(CARDINAL(Int1));    (* INTEGER to REAL  *)

(* Int1  := TRUNC(Real1) + Int2 * 3;         Incompatible error 1 *)
   Int1  := TRUNC(Real1) + CARDINAL(Int2) * 3;     (* error fixed *)
   Int1  := INTEGER(TRUNC(Real1)) + Int2 * 3;      (* error fixed *)

(* Card1 := TRUNC(Real1) + Int2 * 3;         Incompatible error 2 *)
   Card1 := INTEGER(TRUNC(Real1)) + Int2 * 3;      (* error fixed *)
   Card1 := TRUNC(Real1) + CARDINAL(Int2) *3;      (* error fixed *)

   Char1 := "A";
(* Int1  := ORD(Char1) + Int2;               Incompatible error 3 *)
   Int1  := INTEGER(ORD(Char1)) + Int2;            (* error fixed *)
   Int1  := ORD(Char1) + CARDINAL(Int2);           (* error fixed *)

   Card1 := ORD(Char1) + Card1;
   Real2 := FLOAT(ORD(Char1)) + 1.2345;

   Char1 := CHR(TRUNC(FLOAT(ORD(Char1))));      (* Sheer Nonsense *)

END Transfer.

In line 13, the calculations are done in INTEGER format, but due to the assignment compatibility of INTEGER and CARDINAL, the result is converted to CARDINAL across the ":=". Line 16 is an illustration of mixed mathematics using the transfer procedure INTEGER. Line 20 is the first example of "nested" procedures which must be done because FLOAT only uses a CARDINAL for an argument.

The expression in line 22 is an error because TRUNC results in a CARDINAL which cannot be added to an INTEGER. Either of the next two lines fix the problem by making the addition type-compatible then making use of the assignment compatibility between INTEGER and CARDINAL for line number 23. The same error occurs in line 26 and is fixed the same way in either of the next two lines. Once again, in line 31, the incompatible type error occurs and is fixed in either of two ways in the next two lines.

Lines 35 and 36 illustrate converting CHAR data to first CARDINAL then REAL which requires nested procedure calls. The last line of the program is a nest of procedures which converts a character from CHAR to CARDINAL, then to REAL, back to CARDINAL, and finally back to the original CHAR variable. It does nothing except act as a good illustration to you of what can be done.

Conversion between types is very important. You will use these techniques often so it is important to know how they work. A very simple yet helpful memory aid is to remember that any simple type can be converted to CARDINAL and CARDINAL can be converted to any type. Most other conversions require two steps to get from one to the other.

Chapter 14 will readdress this topic with even more extensive type transfer procedures.


1. Write a program in which you define, using the CHAR type variable, the letters "a" and "z", and the numbers "0" and "9". Convert them to CARDINAL, and display the four characters and their ASCII (numerical) values.

2. Write a program that you can easily modify to experiment with conversions between the various types that result in incorrect conversions to see the results on your compiler. For example, convert a -1 as an INTEGER to a CARDINAL.

Chapter 4 - Modula-2 Loops and Control Structures

Loops are some of the most important and most used constructs in computer programming and in all parts of your life. You use loops all the time for many things. Walking is a repetition of putting one foot in front of the other until you get where you are going. Eating a sandwich involves a loop of eating, chewing, swallowing, etc. In this chapter we will first cover all of the possible loops you can define in Modula-2, then go on to the control structures, the decision makers.

Load and display the program LOOPDEMO.MOD. This is a rather large program compared to the ones we have seen so far, but I felt it would be better to cover all of the loops in one file than have you compile and run 4 different files.

(* Chapter 4 - Program 1 *)
MODULE LoopDemo;

FROM InOut IMPORT WriteString, WriteInt, WriteLn, Write;

CONST Where = 11;

VAR  Index   : INTEGER;
     What    : INTEGER;
     Letter  : CHAR;


   WriteString("REPEAT loop     = ");
   Index := 0;
     Index := Index + 1;
   UNTIL Index = 5;          (* This can be any BOOLEAN expression *)

   WriteString("WHILE loop      = ");
   Index := 0;
   WHILE Index < 5 DO        (* This can be any BOOLEAN expression *)
      Index := Index + 1;

   WriteString("First FOR loop  = ");
   FOR Index := 1 TO 5 DO

   WriteString("Second FOR loop = ");
   FOR Index := 5 TO 25 BY 4 DO

(* Note - The four loops above could use a CARDINAL type variable
          in place of the INTEGER type variable Index.  The next 2
          examples must use an INTEGER type variable because it
          must be capable of storing a negative value.            *)

   WriteString("Third FOR loop  = ");
   FOR Index := 5 TO -35 BY -7 DO

   What := 16;
   FOR Index := (What - 21) TO (What * 2) BY Where DO
      WriteString("Fourth FOR loop = ");

(* Note - The next two loops are demonstrations of using a CHAR
          type variable to index a FOR loop.                      *)

   FOR Letter := "A" TO 'Z' DO

   FOR Letter := 'z' TO 'a' BY -1 DO

(* Note - The following loop contains an EXIT which is a way to get
          out of the loop in the middle.                           *)

   Index := 1;
      WriteString("In the EXIT loop ");
      IF Index = 5 THEN
      WriteString("  We are still in the loop.");
      Index := Index + 1;

END LoopDemo.


Ignoring the declaration part of the listing and going straight to the program itself, we first come to the REPEAT loop which does just what it says it will do. It will repeat until it is told to stop. The REPEAT in line 16 and the UNTIL go together, and everything between them will be executed until the condition following the UNTIL becomes TRUE. The condition can be any expression that will evaluate to a BOOLEAN answer, TRUE or FALSE. It can even be a composite expression with AND's, OR's, and NOT's like we studied in the last chapter. It can be composed of any of the simple types discussed so far as long as the terms are all compatible and it evaluates to a BOOLEAN value. In this case we have a very simple expression, "Index = 5". Since "Index" is initialized to 0 and is incremented each time we go through the loop, it will eventually reach a value of 5 and the loop will terminate, after which time the expressions following it will be executed.

We are not quite finished with the REPEAT loop yet, we will have more to say about it when we complete the WHILE loop.


The WHILE loop is very much like the REPEAT loop except that the condition is tested at the beginning of the loop and when the condition becomes FALSE, the loop is terminated. Once again, the condition can be as complex as desired but in this case it is the very simple "Index < 5". When Index reaches 5, the loop is terminated and the statements following the loop are executed.

The biggest difference between the REPEAT and the WHILE loops is concerned with when the test is made. In the WHILE loop, the test is made at the beginning, so it is possible that the statements inside the loop will not be executed even once. In the REPEAT loop, the test is made at the end of the loop, so the statements in the loop will always be executed at least once. It is also good to keep in mind that the REPEAT stops when its condition goes TRUE, and the WHILE stops when its condition goes FALSE.

There is another loop that we can use in which we exit from the center using any test we can devise. It will be covered after we complete the FOR loop.


The FOR loop exists in one form or another in nearly every programming language and you will use it repeatedly because it is so useful. It uses the reserved words FOR, TO, BY, DO, and END. It uses any simple variable type except REAL, and counts loops depending on what counts you put in for beginning and ending points. The first example on line 31 says for the computer to start "Index" at 1 and count to 5, going through the loop once for each value of "Index". The count advances by 1 each time because nothing else is specified and 1 is the default. The end of the loop is specified by the reserved word END, and as many statements as desired can be within the body of the loop.

The next loop starts in line 37 and this time counts from 5 to 25 but incrementing by 4 each time because of the "BY 4" part of the line. The loop will continue until the second limit is going to be exceeded, at which time the loop will stop. The beginning and ending limits can themselves be some kind of a calculated value or a constant, the only provision being that they must be of the same type as the loop indexing variable. In fact they can be negative and the increment value can be negative. This is illustrated in the next loop that starts in line 48 where we count by -7 until we go from 5 to -35. No further explanation should be required for this loop.

The next loop, starting in line 54, uses calculated limits to determine its starting and ending points and it uses the name "Where" for its incrementing value. The value of "Where" is established in the definition part of this program as a constant. It is simply used here and will be explained in a future lesson when we get to it. "Where" is a constant with a value of 11, and the incrementing value must always be a constant.

The next two FOR loops use a CHAR type variable and simply "count" from "A" to "Z", or backwards in the case of the second one.

Several things should be pointed out about the FOR loop for you. The three values must agree in type, that is the index, the starting point, and the ending point. The index must not be changed by any logic within the loop or the results will be unpredictable. The value of the index must be assumed to be undefined after the loop terminates. You may discover that it is predictable on your compiler, but it may not be on some other compiler, and you may want to transfer your program to another system someday.


The fourth and final loop is an infinite loop, it never terminates by itself. It is up to you the programmer to see to it that some means of terminating it is available, the most usual is through use of the EXIT statement. Anyplace in the loop you can set up some conditions for exiting based on whatever you desire. Executing the EXIT procedure will cause the program control to leave the loop and begin executing the statements following the loop.

Now you have been exposed to the four loops available in Modula-2, the REPEAT, WHILE, FOR, and LOOP. Spend some time studying this program, then compile and run it to see if it does what you expect it to do. Loops are very important. You will do the vast majority of your logical control in loops and IF statements.


Load the program IFDEMO.MOD and display it on your monitor for an example of some IF statements. Ignoring the header we notice that the program is composed of one big loop in order to have some changing variables. Within the loop are 3 IF statements, the most used conditional statement in Modula-2.

(* Chapter 4 - Program 2 *)

FROM InOut IMPORT WriteString, WriteInt, WriteLn;



   FOR Index1 := 1 TO 8 DO
      IF Index1 < 4 THEN                   (* Simple IF statement *)
         WriteString("Index1 is less than 4.");
      END;  (* end of first IF statement *)

      IF Index1 = 5 THEN                   (* two way IF statement *)
         WriteString("Index1 is 5");
         WriteString("Index1 is not 5");
      END;  (* end of second IF statement *)

      IF Index1 = 2 THEN              (* multiple way IF statement *)
         WriteString("Index1 is 2");
      ELSIF Index1 = 6 THEN
         WriteString("Index1 is 6");
         WriteString("I really don't care what Index1 is");
      END;  (* end of third IF statement *)
   END;  (* of big FOR loop *)

END IfDemo.

The first IF statement is given in line 11. It simply says "if the value of Index1 is less than 4, then" do everything from the reserved word THEN to the reserved word END which is associated with it. If the value of Index1 is not less than 4, then all of these statements are ignored and the next statement to be executed will be the one following the reserved word END. In a nutshell, that is all there is to the simple IF statement. Once again, the condition can be any expression that will evaluate to a BOOLEAN result, and it can be composed of any of the simple types of data elements.


The second IF statement, beginning in line 17 has an added feature, the ELSE clause. If the BOOLEAN expression does not evaluate to TRUE, then instead of the expressions following the THEN being executed, the group following the ELSE will be. Thus, if it is TRUE, everything from the THEN to the ELSE is executed, but if it is FALSE, everything from the ELSE to the END is executed. The END statement is therefore the terminator for the effect of the IF statement.


You may be wondering what is allowed to go into the group of executable statements between the THEN and the ELSE or some other place. The answer is, anything you want to put there. You can put other IF statements, loops, input or output statements, calculations, just about anything. If you indent the statements properly, you will even be able to read and understand what you put in there and why you put it there. Of course, if you put a loop in there, for example, you can put other constructs within the loop including other IF statements, etc. Thus you can go as far as you desire in building up a program.


The third and last kind of IF statement is given in the third example starting on line 24. In this case, if the expression within the IF statement is found to be FALSE, the statements following the THEN are skipped and the next construct is found, the ELSIF. If program control comes here, it has a further expression to evaluate, which if TRUE, will cause the statements immediately following its THEN to be executed. If this expression is found to be FALSE, the statements following the ELSE will be executed. The net result is that, one and only one of the 3 groups of instructions will be executed each time through the loop. It is permissible to add as many ELSIF cases as desired to this construct, leading to a "many way" branch. In addition, the ELSE is entirely optional regardless of whether or not the ELSIF's are used.

After studying this program, compile and run it and compare the results with what you expected.


Load and display the next example program LOOPIF.MOD for an example of some of the latest topics being combined. This program makes nonsense data but is valuable because it is small enough to understand quickly to see how LOOP's and IF's can be nested together. The entire program is a FOR loop containing an IF statement. Each part of the IF statement has a loop nested within it. There is no reason why this process could not be continued if there were a need to. Study this program then compile and run it.

(* Chapter 4 - Program 3 *)

FROM InOut IMPORT WriteString, WriteInt, WriteLn;

VAR Index, Count, Dog : INTEGER;

   FOR Index := 1 TO 10 DO
      WriteString("Major loop");
      IF Index < 7 THEN
         FOR Count := 15 TO (15 + Index) DO
            WriteString(' XXX');
         WriteString(' How many dogs?');
         FOR Dog := 1 TO 10 - Index DO
            WriteString("  too many");
      END;  (* ELSE part of IF statement *)

   END (* Major FOR loop *)
END LoopIf.


Load and display the program named TEMPCONV.MOD for your first look at a program that really does do something useful. This is a program that generates a list of temperatures in centigrade, converts the list to farenheit, and displays the list along with a note in the table at the freezing point and boiling point of water. You should have no difficulty understanding this program, so the fine points will be left up to you.

(* Chapter 4 - Program 4 *)

(* This program is a good example of proper formatting, it is   *)
(* easy to read and very easy to understand.  It should be a    *)
(* snap to update a program that is well written like this. You *)
(* should begin to develop good formatting practice early in    *)
(* your programming career.                                     *)

MODULE TempConv;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;

VAR Count      : INTEGER;   (* a variable used for counting     *)
    Centigrade : INTEGER;   (* the temperature in centigrade    *)
    Farenheit  : INTEGER;   (* the temperature in farenheit     *)


   WriteString("Farenheit to Centigrade temperature table");

   FOR Count := -2 TO 12 DO
      Centigrade := 10 * Count;
      Farenheit := 32 + Centigrade *9 DIV 5;
      WriteString("   C =");
      WriteString("     F =");
      IF Centigrade = 0 THEN
         WriteString("   Freezing point of water");
      IF Centigrade = 100 THEN
         WriteString("   Boiling point of water");
   END; (* of main loop *)

END TempConv.

A few comments on good formatting is in order at this point. Notice the temperature conversion program and how well it is formatted. It is simple to follow the flow of control, and the program itself needs no comments because of the judicious choice of variable names. The block header at the top of the page is a good example of how you should get used to defining your programs. A simple block header of that variety goes a long way toward making a program maintainable and useful later. Take notice also of the way the variables are each defined in a comment. A program as simple as this probably doesn't need this much attention, but it would be good for you to get into practice early. It would be good for you to think of each of your programs as a work of art and strive to make them look good.

After spending some time studying this program, compile and run it to see what it does. Load and study the next program named DUMBCONV.MOD to see if you can figure out what it does. If you are really sharp, you will see that it is the same program as the last one but without all of the extra effort to put it into a neat, easy to follow format. Compile and run this program and you will see that they both do the same thing. They are identical as far as the computer is concerned. But there is a world of difference in the way they can be understood by a human being.

(* Chapter 4 - Program 5 *)
MODULE DumbConv;
FROM InOut IMPORT WriteString, WriteInt, WriteLn;
VAR a, b, c : INTEGER;
   WriteString("Farenheit to Centigrade temperature table");
   FOR a := -2 TO 12 DO
      b := 10 * a;
      c := 32 + b *9 DIV 5;
      WriteString("   C =");
      WriteString("     F =");
      IF b = 0 THEN
         WriteString("   Freezing point of water");
      IF b = 100 THEN
         WriteString("   Boiling point of water");
   END; (* of main loop *)

END DumbConv.


Load and display the program named CASEDEMO.MOD for an example of the last decision making construct in Modula-2, the CASE statement. A CASE statement is a "many-way" branch based on some simple variable. In this program we have a loop which sets the variable "Dummy" to the values from 1 to 25 successively. Each time it comes to the CASE statement, one of the branches is taken. The first branch is taken if the value is from 1 to 5, the second branch is taken if the value is from 6 to 9, the third is taken if it is either a 10 or 11, etc. Finally, if the value is not found in any of the branches, the ELSE path is taken as would be the case of a 12, a 13, or a few others. The important point is that one and only one of the many paths are taken each time the CASE construct is entered. The CASE variable can be any of the simple types except for the REAL type. For each path, as many statements can be executed as desired before the "|" is put in to end that path. The CASE statement is a powerful statement when you need it but you will not use it nearly as often as you will use the IF statement and the various loops.

(* Chapter 4 - Program 6 *)
MODULE CaseDemo;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;



   FOR Dummy := 1 TO 25 DO
      WriteString("  ");
      CASE Dummy OF
         1..5        : WriteString("the number is small"); |
         6..9        : WriteString("it is a little bigger"); |
         10,11       : WriteString("it is 10 or 11"); |
         14..17      : WriteString("it is midrange"); |
         18,20,22,24 : WriteString("it is big and even"); |
         19,21,23    : WriteString("it is big and odd");
         WriteString("The number didn't make the list");
      END;  (* of CASE *)
   END;  (* of FOR loop *)

END CaseDemo.


1. Write a program that will put your name on the monitor 10 times using a loop.

2. Write a program that lists the numbers from 1 to 12 on the monitor and prints a special message beside the number that represents the month of your birthday.

3. Write a program that calculates and lists the numbers from 1 to 8 along with the factorial of each. This will require use of a loop within a loop. A factorial is the number obtained by multiplying each number less than and up to the number in question. For example, factorial 4 = 1 * 2 * 3 * 4. Use a CARDINAL type var- iable for the result, then change it to an INTEGER to see the difference in output due to the range of the two different variable types. This is a good illustra- tion of the fact that careful choice of variable type is sometimes very important.

Chapter 5 - Modula-2 Procedures

In order to define the procedure, we will need to lay some groundwork in the form of a few definitions.

Program Heading - This is the easiest part since it is only one line, at least it has been in all of our programs up to this point. It is simply the MODULE line, and it never needs to be any more involved than it has been up to this point, except for one small addition which we will cover in a later chapter.

Declaration Part - This is the part of the Modula-2 source code in which all constants, variables, and other user defined auxiliary operations are defined. In some of the programs we have examined, there have been one or more VAR declarations and in one case a constant was declared. These are the only components of the declaration part we have used up to this time. There are actually four components in the declaration part, and the procedures make up the fourth part. We will cover the others in the next chapter.

Statement Part - This is the last part of any Modula-2 program, and it is what we have been calling the main program. It always exists bounded by the reserved words BEGIN and END just as it has in all of our examples to this point.

It is very important that you grasp the above definitions because we will be referring to them constantly during this chapter, and throughout the remainder of this tutorial. With that introduction, let us look at our first Modula-2 program with a procedure in it. It will, in fact, have three procedures.


A Procedure is a group of statements, either predefined by the compiler writer, or defined by you, that can be called upon to do a specific job. In this chapter we will see how to write and use a procedure. During your programming in the future, you will use many procedures. In fact, you have already used some because the "WriteString", "WriteLn", etc procedures you have been using are predefined procedures.

Load and display the program named PROCED1.MOD for your first look at a user defined procedure. In this program, we have the usual header with one variable defined. Ignore the header and move down to the main program beginning with line 26. We will come back to all of the statements prior to the main program in a few minutes.

(* Chapter 5 - Program 1 *)
MODULE Proced1;

FROM InOut IMPORT WriteString, WriteLn;


PROCEDURE WriteHeader;
   WriteString("This is the header");
END WriteHeader;

PROCEDURE WriteMessage;
   WriteString("This is the message");
END WriteMessage;

PROCEDURE WriteEnding;
   WriteString("This is the end");
END WriteEnding;

BEGIN        (* Main program *)
   FOR Count := 1 TO 8 DO
END Proced1.

The main program is very easy to understand based on all of your past experience with Modula-2. First we somehow write a header (WriteHeader), then write a message out 8 times (WriteMessage), and finally we write an ending out (WriteEnding). Notice that with the long names for the parts, no comments are needed, the program is self documenting. The only problem we have is, how does the computer actually do the three steps we have asked for. That is the purpose for the 3 procedures defined earlier starting in lines 8, 14, and 20. Modula-2 requires that nothing can be used until it has been defined, so the procedures are required to be defined prior to the main program. This may seem a bit backward to you if you are experienced in some other languages like FORTRAN, BASIC, or C, but it will make sense eventually.


We will begin with the PROCEDURE at line 8. First we must use the reserved word PROCEDURE followed by the name we have chosen for our procedure, in this case "WriteHeader" which is required to follow all of the rules for naming an identifier. Following the PROCEDURE line, we can include more IMPORT lists, define variables, or any of several other things. We will go into a complete definition of this part of the program in the next chapter. I just wanted to mention that other quantities could be inserted here. We finally come to the procedure body which contains the actual instructions we wish to execute in the procedure. In this case, the procedure body is very simple, containing only a "WriteString" and a "WriteLn" instruction, but it could have been as complex as we needed to make it.

At the end of the procedure, we once again use the reserved word END followed by the same name as we defined for the procedure name. In the case of a procedure, the final name is followed by a semicolon instead of a period. Other than this small change, a procedure definition is identical to that of the program itself.

When the main program comes to the "WriteHeader" statement, it knows that it is not part of its standard list of executable instructions, so it looks for the user defined procedure by that name. When it finds it, it transfers control of the program sequence to there, and begins executing those instructions. When it executes all of the instructions in the procedure, it finds the END statement of the procedure and returns to the next statement in the main program. When the main program finally runs out of things to do, it finds the END statement and terminates.

As the program executes the FOR loop, it is required to call the "WriteMessage" procedure 8 times, each time writing its message on the monitor, and finally it finds and executes the "WriteEnding" procedure. This should be very straightforward and should pose no real problem for you to understand. When you think you understand what it should do, compile and run it to see if it does.


The last program was interesting to show you how a procedure works but if you would like to see how to get some data into the procedure, load and display the program named PROCED2.MOD. We will once again go straight to the program starting in line number 25. We immediately notice that the program is nothing more than one big FOR loop which we go through 3 times. Each time through the loop we call several procedures, some that are system defined, and some that are user defined. This time instead of the simple procedure name, we have a variable in the parentheses behind the variable name. In these procedures, we will take some data with us to the procedures, when we call them, just like we have been doing with the "WriteString" and "WriteInt" procedures.

(* Chapter 5 - Program 2 *)
MODULE Proced2;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;

    Thing : INTEGER;

PROCEDURE PrintDataOut(Puppy : INTEGER);
   WriteString("The value of Puppy is     ");
   Puppy := 12;
END PrintDataOut;

   WriteString("The value of Cat is       ");
   Cat := 37;
END PrintAndModify;

BEGIN        (* Main program *)
   FOR Stuff := 3 TO 5 DO
      Thing := Stuff;
         WriteString("Back from print, data is  ");
         WriteString("Back from modify, data is ");
         WriteString("Back from print, data is  ");
END Proced2.

We will take some data to the procedure named "PrintDataOut" where it will be printed. The procedure "PrintDataOut" starting in line 9 also contains a pair of parentheses with a variable named "Puppy" which is of type INTEGER. This says that it is expecting a variable to be passed to it from the calling program and it expects the variable to be of type INTEGER. Back to the main program we see, on line 28, that the program did make the call to the procedure with a variable named "Thing" which is an INTEGER type variable, so everything is fine. The procedure prefers to call the variable passed to it "Puppy" but that is perfectly acceptable, it is the same variable. The procedure writes the value of "Puppy", which is really the variable "Thing" in the main program, in a line with an identifying string, then changes the value of "Puppy" before returning to the main program.

Upon returning to the main program, we print out another line with three separate parts (notice the indenting and the way it makes the program more readable), then calls the next procedure "PrintAndModify" which appears to do the same thing as the last one. Indeed, studying the procedure itself leads you to believe they are the same, except for the fact that this one prefers to use the name "Cat" for a variable name. There is one subtle difference in this procedure, the reserved word VAR in the header, line 17.


In the first procedure, the word VAR was omitted. This is a signal to the compiler that this procedure will not actually receive the variable reference, instead it will receive a local copy of the variable which it can use in whatever way it needs to. When it is finished, however, it can not return any changes in the variable to the main program because it can only work with its copy of the variable. This is therefore a one-way variable, it can only pass data to the procedure. This is sometimes called a "call by value" or a "value parameter" in literature about Modula-2.

In the second procedure, the word VAR was included. This signals the compiler that the variable in this procedure is meant to be actually passed to the procedure, and not just the value of the variable. The procedure can use this variable in any way it desires, and since it has access to the variable in the main program, it can alter it if it so desires. This is therefore a two-way variable, it can pass data from the main program to the procedure and back again. This is sometimes called a "call by reference" or a "variable parameter" in literature about Modula-2.


It is up to you to decide which of the two parameter passing schemes you should use for each application. The "two-way" scheme seems to give the greatest flexibility, so your first thought is to simply use it everywhere. But that is not a good idea because it gives every procedure the ability to corrupt your main program variables. In addition, if you use a "call by value" in the procedure definition, you have the ability to call the procedure with a constant in that part of the call. A good example is given in lines 12, 20, 30, 34, and 38 of the present program. If "WriteInt" were defined with a "call by reference", we could not use a constant here, but instead would have to set up a variable, assign it the desired value, then use the variable name instead of the 5. There are other considerations but they are beyond the level of our study at this point.


We have already mentioned that both of the procedures modify their respective local variables, but due to the difference in "call by value" in the first, and "call by reference" in the second, only the second can actually get the modified data back to the calling program. This is why they are named the way they are. One other thing should be mentioned. Since it is not good practice to modify the variable used to control the FOR loop, (and downright erroneous in many cases) we make a copy of it and call it "Thing" for use in the calls to the procedures. Based on all we have said above, you should be able to figure out what the program will do, then compile and run it.


Load and display the program named PROCED3.MOD for an example of a procedure definition with more than one variable being passed to it. In this case four parameters are passed to this procedure. Three of the parameters are one-way and one is a two-way parameter. In this case we simply add the three numbers and return it to the main program. Good programming practice would dictate the placement of the single "call by reference" by itself and the others grouped together, but it is more important to demonstrate to you that they can be in any order you desire. This is a very straightforward example that should pose no problem to you. Compile and run it.

(* Chapter 5 - Program 3 *)
MODULE Proced3;

FROM InOut IMPORT WriteString, WriteCard, WriteLn;

VAR Apple, Orange, Pear, Fruit : CARDINAL;

PROCEDURE AddTheFruit (Value1,Value2 : CARDINAL;  (* One-way *)
                       VAR Total     : CARDINAL;  (* Two-way *)
                       Value3        : CARDINAL); (* One-way *)
   Total := Value1 + Value2 + Value3;
END AddTheFruit;

BEGIN  (* Main Program *)
   Apple := 4;
   Orange := 7;
   Pear := 5;
   WriteString("The total number of fruits is ");
END Proced3.


Load and display the program PROCED4.MOD for a program which can be used to define scope of variables or where variables can be used in a program. The three variables defined in lines 6, 7, and 8, are of course available in the main program because they are defined prior to it. The two variables defined in the procedure are available within the procedure because that is where they are defined. However, because the variable "Count" is defined both places, it is two completely separate variables. The main program can never use the variable "Count" defined in the procedure, and the procedure can never use the variable "Count" defined in the main program. They are two completely separate and unique variables with no ties between them. This is useful because when your programs grow, you can define a variable in a procedure, use it in whatever way you wish, and not have to worry that you are corrupting some other "global" variable. The variables in the main program are called "global variables" because they are available everywhere.

(* Chapter 5 - Program 4 *)
MODULE Proced4;

FROM InOut IMPORT WriteString, WriteCard, WriteLn;

    Index : CARDINAL;
    Other : CARDINAL;

PROCEDURE PrintSomeData;
    Apple : CARDINAL;
   Count := 7;
   Other := 12;
   Apple := 32;
   WriteString("In PrintSomeData the variables are");
END PrintSomeData;

BEGIN    (* Main program *)
   FOR Index := 1 TO 3 DO
      Count := Index;
      Other := Index;
         WriteString("In Main Program the variables are ");
         WriteString("In Main Program the variables are ");
   END;  (* of FOR loop *)
END Proced4.

In addition to the above scope rules, the variable named "Apple" in the procedure, is not available to the main program. Since it is defined in the procedure it can only be used in the procedure. The procedure effectively builds a wall around the variable "Apple" and its own "Count" so that neither is available outside of the procedure. We will see in the next chapter that procedures can be "nested" leading to further hiding of variables. This program is intended to illustrate the scope of variables, and it would be good for you to study it, then compile and run it.


Load and display the program named PROCED5.MOD for an example of procedures that call other procedures. Study of this program will reveal that procedure "Three" starting on line 19 calls procedure "Two" which in turn calls procedure "One". The main program calls all three, one at a time, and the result is a succession of calls which should be rather easy for you to follow. The general rule is, "any program or procedure can call any other procedure that has been previously defined, and is visible to it." (We will say more about visibility later.) Study this program then compile and run it.

(* Chapter 5 - Program 5 *)
MODULE Proced5;

FROM InOut IMPORT WriteString, WriteLn;

   WriteString("This is procedure One.");
END One;

   WriteString("This is procedure Two.");
END Two;

   WriteString("This is procedure Three.");
END Three;

BEGIN   (* Main program *)
END Proced5.


Load and display the program named FUNCTION.MOD for an example of a "Function Procedure". This contains a procedure very much like the ones we have seen so far with one difference. In the procedure heading, line 6, there is an added ": INTEGER" at the end of the argument list. This is a signal to the system that this procedure is a "function procedure" and it therefore returns a value to the calling program in a way other than that provided for by parameter references as we have used before. In fact, this program returns a single data value that will be of type INTEGER.

(* Chapter 5 - Program 6 *)
MODULE Function;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;

PROCEDURE QuadOfSum(Number1, Number2 : INTEGER) : INTEGER;
   RETURN(4*(Number1 + Number2));
END QuadOfSum;

VAR Dogs, Cats, Feet : INTEGER;

BEGIN  (* Main program *)
   Dogs := 4;
   Cats := 3;
   Feet := QuadOfSum(Dogs,Cats);
   WriteString("There are a total of");
   WriteString(" paws.");
END Function.

In line 16 of the calling program, we find the call to the procedure which looks like the others we have used except that it is used in an assignment statement as though it is an INTEGER type variable. This is exactly what it is and when the call is completed, the "QuadOfSum(Dogs,Cats)" will be replaced by the answer and then assigned to the variable "Feet". The entire call can therefore be used anyplace in a program where it is legal to use an INTEGER type variable. This is therefore a single value return and can be very useful in the right situation. In one of the earlier program, we used the "sin" and "cos" function procedures and this is exactly what they were.

One additional point must be made here. If a function procedure does not require any parameters, the call to it must include empty parentheses, and the definition of the procedure must include empty parentheses also. This is by definition of the Modula-2 language.

In the procedure, we had to do one thing slightly different in order to get the return value and that was to use the RETURN reserved word. Whenever we have completed the desired calculations or whatever we need to do, we put the result that is to be returned to the main program in the parentheses following the RETURN and the procedure will terminate, return to the calling program, and take the value with it as the answer. Due to decision making, we may have several RETURN statements in the procedure but only one will be exercised with each call. It is an error to come to the END statement of a function procedure since that would constitute a return without the benefit of the RETURN statement, and no value would be returned to the calling program.


Recursion is simply a procedure calling itself. If you have never been introduced to recursion before, that definition sounds too simple but that is exactly what it is. You have probably seen a picture containing a picture of itself. The picture in the picture also contains a picture of itself, the end result being an infinity of pictures. Load the file named RECURSON.MOD for an example of a program with recursion.

(* Chapter 5 - Program 7 *)
MODULE Recurson;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;


PROCEDURE PrintAndDecrement(Index : INTEGER);
   WriteString("The value of the Index is");
   Index := Index - 1;
   IF Index > 0 THEN
END PrintAndDecrement;

BEGIN    (* Main program *)
   Count := 7;
END Recurson.

In the main program, "Count" is set to 7 and the procedure is called taking along "Count" as a parameter. In the procedure, we display a line containing the value of the variable, now called "Index", and decrement it. If the variable is greater than zero, we call the same procedure again, this time entering it with the value of 6. It would be reasonably correct to think of the system as creating another copy of the procedure for this call. The variable "Index" would be reduced to 5, and another copy of the procedure would be called. Finally, the variable would be reduced to zero and the return path from procedure to procedure would be taken until the main program would be reached, where the program would terminate.

Rather than making a complete new copy of the procedure for each recursive call, the same code would be run each time through and all of the data would be stored away on the "stack" each time through. You have no need to worry about this because it is all taken care of for you by the system. You simply call the same procedure as though it were any other procedure and the system will worry about all of the details except for one. It is up to you to see that there is some mechanism by which the process will terminate. If there were no decrementing statement in the procedure, this program would never reach an end and the stack would overflow, resulting in an error message and termination of the program. It would be worth your time to remove the decrementing statement and observe this, after you compile and run it the way it is now.

Recursion can be very useful for those problems that warrant its use. This example is a very stupid use of recursion, but is an excellent method for giving an example of a program with recursion that is simple and easy to understand.


This example uses direct recursion because the procedure calls itself directly. It is also possible to use indirect recursion where procedure "A" calls "B", "B" calls "A", etc. Either method is available and useful depending on the particular circumstances.


1. Write a program to write your name, address, and phone number on the monitor with each line in a different procedure.

2. Add a statement to the procedure in RECURSON to display the value of "Index" after the call to itself so you can see the value increasing as the recurring calls are returned to the next higher level.

3. Rewrite TEMPCONV from chapter 4 putting the centigrade to farenheit formula in a function procedure.

Chapter 6 - Arrays, Types, and Constants

Load the program named ARRAYS.MOD and we will go right to our first example of an array. An array is simply a list made up of several of the same type of element. Notice the VAR definition in the sample program and specifically the variable named "Automobiles". The reserved word ARRAY followed by the square brackets with a range of numbers contained within them is the proper way to define an array of, in this case, CARDINAL type variables. This defines 12 different CARDINAL type variables, each of which is capable of storing one CARDINAL number. The names of the twelve variables are given by Automobiles[1], Automobiles[2], ... Automobiles[12]. The variable name is "Automobiles" and the array subscripts are the numbers 1 through 12. The variables are true CARDINAL type variables and can be assigned values, or they can be used in calculations or in nearly anyplace in a program where it is legal to use a CARDINAL type variable. One place they cannot be used is as the index for a FOR loop since a simple variable type is required there.

(* Chapter 6 - Program 1 *)
MODULE Arrays;

FROM InOut IMPORT WriteString, WriteCard, WriteLn;

VAR Index       : CARDINAL;
    Automobiles : ARRAY [1..12] OF CARDINAL;

BEGIN   (* main program *)
   FOR Index := 1 TO 12 DO
      Automobiles[Index] := Index + 10;
   Automobiles[7] := 54;  (* example, change one value of array *)
   WriteString("This is the first program with an array.");
   WriteLn;                       (* end of data initialization *)

   FOR Index := 1 TO 12 DO              (* display the data now *)
      WriteString("Automobile number");
      WriteString(" has the value of");
END Arrays.


Notice lines 10 through 12 of the program. In these lines, each of the 12 variables is assigned a value. When "Index" is 1, then "Automobiles[1]" is assigned 11, then when "Index" is 2, "Automobiles[2]" is assigned 12, etc.

If the 12 variables were defined as 12 separate variables of whatever names we chose for them, we could not assign them values in a loop but would have to assign each one independently. In this instance, we are generating nonsense data but in a real program, this loop could be reading in a series of data from a file such as would be done with a database. The advantage of the array should be very clear, especially if we were to change the array limits to several thousand elements.

The statement in line 13 assigns a value to one of the elements at random to illustrate the method. Notice that the 7th element of the array named "Automobiles" is assigned the value of 54. The address of this data is therefore the variable name "Automobiles[7]" and the data contained in that address is 54. We have therefore assigned values to the 12 variables by a nonsensical but known scheme, and now we can use the 12 variables in any way that is legal within Modula-2.

The next loop causes the 12 values to be displayed on the monitor in a neat orderly fashion. In line 20 we display the index of the variable in question, and in line 22, we display the actual variable. Keep in mind that the

index could have been INTEGER and still be used to display an array of type CARDINAL provided we defined "Index" as an integer and always used it as such. Spend enough time with this program so that you thoroughly understand it, then compile and run it.


Modula-2 does very strong "type checking" and limit checking. If, in the above program, you tried to assign a value to "Automobiles[13]", which doesn't exist, a run time error would be generated and the program would cease. This is one of the advantages of Modula-2 over some of the older programming languages. Some compilers have the ability to enable or disable this feature.


Load the file named ARRAYS2.MOD for an example of a program with two-dimensional arrays. In this program, the VAR section contains the "Checkerboard" variable which is defined as an 8 element ARRAY in which each element is an 8 element ARRAY, therefore being an 8 by 8 square ARRAY. Each element is capable of storing one CARDINAL type variable. The variable "Value" is defined the same way except that the method of definition is slightly different. The two methods result in the same type and number of variables.

(* Chapter 6 - Program 2 *)
MODULE Arrays2;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;

VAR  Index, Count     : CARDINAL;
     Checkerboard     : ARRAY[1..8] OF ARRAY[1..8] OF CARDINAL;
     Value            : ARRAY[1..8],[1..8] OF CARDINAL;

   FOR Index := 1 TO 8 DO
      FOR Count := 1 TO 8 DO
         Checkerboard[Index,Count] := Index + 3*Count;
         Value[Index,Count] := Index + 2*Checkerboard[Index,Count];
      END;  (* of Count loop *)
   END;     (* of Index loop *)

   WriteString("Output of checkerboard");
   FOR Index := 1 TO 8 DO
      FOR Count := 1 TO 8 DO
      END;  (* of Count loop *)
   END;     (* of Index loop *)

   Value[3,5] := 77;   (* change a few of the values *)
   Value[3,6] := 3;
   Value[Value[3,6],7] := 2;  (* same as Value[3,7] := 2; *)

   WriteString("Output of Value matrix");
   FOR Count := 1 TO 8 DO
      FOR Index := 1 TO 8 DO
      END;   (* of Index loop *)
   END;      (* of Count loop *)
END Arrays2.

In lines 11 through 16 we have two nested FOR loops. The outer loop causes "Index" to count from 1 to 8 and for each value of "Index", the variable "Count" counts through the values 1 to 8 also. The net result is that we evaluate the assignments in lines 13 and 14 once for each possible combination of "Index" and "Count". For each combination, we assign some nonsense data to "Checkerboard" then use the result of that calculation to assign some nonsense data to the variable "Value". The purpose here is to illustrate the method of using the double subscripted variables. Next we display the entire matrix of "Checkerboard". The loops cause 8 values to be displayed on one line so that the entire matrix is displayed on only 8 lines. You should study this logic because you will find output sequences like this to be very valuable.


In line 27 and following we change a few of the values at random for illustrative purposes. Since "Value[3,6]" is assigned the value of 3, it can be used as one of the subscripts of the next line and in fact it is. This would be a rather sloppy programming style but it is a good illustration of what can be done. Finally using the same technique as that for "Checkerboard", the "Value" matrix is displayed.


There is no limit as to how many subscripts can be used in Modula-2 by definition, but there is a practical limit of somewhere in the range of 3 or 4. If you use too many, you will very quickly get confused and lose control of what the program is supposed to be doing. I have never seen more than 3 subscripts used in any programming language, and very few instances of more than two. Let the problem definition be your guide.

This program was pretty straightforward, and it is time for you to compile and run it.


Load the program named TYPES.MOD for a new topic that you will use often, especially in large programs. At the top of the listing we have a group of TYPE declarations. The first line defines "ArrayDef" as a new TYPE definition that can be used in the same way you would use INTEGER or any of the other simple type definitions. In line 12, the variable named "Stuff" is defined as a variable of type "ArrayDef", and since "ArrayDef" is a 14 element ARRAY, then "Stuff" is a 14 element array of INTEGER. It seems like we didn't save anything and in fact we added a few keystrokes to the program in order to do this. If you look at line 13 you will see that we have also defined "Stuff2" as the same type of array. We have, in fact, defined them to be "type compatible" which will be very important when we get to the program itself.

(* Chapter 6 - Program 2 *)
MODULE Arrays2;

FROM InOut IMPORT WriteString, WriteInt, WriteLn;

VAR  Index, Count     : CARDINAL;
     Checkerboard     : ARRAY[1..8] OF ARRAY[1..8] OF CARDINAL;
     Value            : ARRAY[1..8],[1..8] OF CARDINAL;

   FOR Index := 1 TO 8 DO
      FOR Count := 1 TO 8 DO
         Checkerboard[Index,Count] := Index + 3*Count;
         Value[Index,Count] := Index + 2*Checkerboard[Index,Count];
      END;  (* of Count loop *)
   END;     (* of Index loop *)

   WriteString("Output of checkerboard");
   FOR Index := 1 TO 8 DO
      FOR Count := 1 TO 8 DO
      END;  (* of Count loop *)
   END;     (* of Index loop *)

   Value[3,5] := 77;   (* change a few of the values *)
   Value[3,6] := 3;
   Value[Value[3,6],7] := 2;  (* same as Value[3,7] := 2; *)

   WriteString("Output of Value matrix");
   FOR Count := 1 TO 8 DO
      FOR Index := 1 TO 8 DO
      END;   (* of Index loop *)
   END;      (* of Count loop *)
END Arrays2.

Continuing down the list of TYPE declarations, we define a TYPE with 28 characters, then a TYPE with 60 real variables, and another with 6 BOOLEAN variables. The next TYPE consists of 12 variables of TYPE "DogFood" which is itself a TYPE of 6 BOOLEANS, resulting in a TYPE consisting of 6 times 12 = 72 BOOLEANS. It is possible to continue building up TYPE definitions like this indefinitely, and as you build up applications, you will find yourself building up rather complex TYPE declarations and having a clear picture of how they go together because it is your solution to a problem. The last TYPE to be defined is that named "Boat" which has exactly the same size and characteristics as "Airplane". We will see shortly that there is a difference in these two definitions.


In the VAR part of the definition part of the program, we declare some variables, two simple types and some of the types we defined above. In the program part, we assign some values to the 72 variables making up the "Puppies" matrix and the 72 variables making up the "Kitties" matrix. All of the elements of "Stuff" are then assigned nonsense values. The really interesting statement comes in line 30 where we say "Stuff2 := Stuff;". In this simple statement, all 14 values stored in "Stuff" are copied into the 14 corresponding elements of "Stuff2" without using a loop. This is possible because the two variables are TYPE compatible, they have the same TYPE definition. If you study the definitions above, you will see that "Stuff3" is of the same number and range of elements and is composed of the same type of elements, namely INTEGER, as "Stuff" but they are not TYPE compatible because were not defined with the same TYPE definition statement. In like manner, even though "Puppies" and "Kitties" are identical in type, they are not TYPE compatible.

You have the ability, through careful assignment of variables, to avoid certain kinds of programming errors. If certain variables should never be assigned to each other, a careful selection of types can prevent it. Suppose for example that you have a program working with peaches and books. You would never want to copy a matrix of peaches to one defining books, it just wouldn't make sense. Those two matrices should be defined with different type declarations even though they may be identical in size.

Compile and run this program, even though it will result in no output, then move the comment delimiter in line 31 to a position following the assignment statement and see if it does give you a TYPE incompatibility error.


Load the program named CONSTANT.MOD for a definition of the constant as used in Modula-2. We will finally keep the promise made when we studied LOOPDEMO in chapter 4. The new reserved word CONST is used to define a constant for use in the program. The constant "MaxSize" can be used anywhere in the program that it is desired to use the number 12, because they are in fact identical. Two additional CONST values are defined for illustrative purposes only. In the TYPE declaration section we use the constant "MaxSize" to define two types, then use them to define several variables.

(* Chapter 6 - Program 4 *)
MODULE Constant;

CONST MaxSize    = 12;
      IndexStart = 49;
      CheckItOut = TRUE;

TYPE  BigArray  = ARRAY[1..MaxSize] OF CARDINAL;
      CharArray = ARRAY[1..MaxSize] OF CHAR;

VAR   AirPlane   : BigArray;
      SeaPlane   : BigArray;
      Helicopter : BigArray;
      Cows       : CharArray;
      Horses     : CharArray;
      Index      : CARDINAL;

BEGIN     (* main program *)
   FOR Index := 1 TO MaxSize DO
      AirPlane[Index] := Index*2;
      SeaPlane[Index] := Index*3 + 12;
      Helicopter[MaxSize - Index + 1] := Index + AirPlane[Index];
      Horses[Index] := 'X';
      Cows[Index] := "R";
   END;   (* of Index loop *)
END Constant.

In the program there is one FOR loop using the same constant "MaxSize" as the upper limit. It doesn't seem to be too useful yet, but suppose your boss came to you and said to change the program so that it handled 142 cases instead of 12. The way the program is written, you would only have to change the value of the constant, recompile, and you would be done. If you had used the number 12 everywhere, you would have to replace every 12 with the new number, 142, being careful not to change the one in line 21 which is a different kind of 12. Of course even that would not be too difficult in such a simple program, but in a program with 5000 lines of code, one simple change could take a week.

Compile and run this program.


Load and display the program named ARAYPASS.MOD for an example of a program with arrays being passed to a procedure. Notice how the procedures are formatted. The rows of asterisks make them really stand out and easy to find. You will develop your own personal style of formatting in a way that is clear and easy to follow for you.

(* Chapter 6 - Program 5 *)
MODULE ArayPass;

FROM InOut IMPORT WriteString, WriteCard, WriteLn;

TYPE OneArray = ARRAY[10..15] OF CARDINAL;
     TwoArray = ARRAY[-8..210] OF CARDINAL;

VAR  SizeOne : OneArray;
     SizeTwo : TwoArray;
     Index   : INTEGER;

(* **************************************************** AddNumbers *)
PROCEDURE AddNumbers(Donkey : OneArray);

VAR CountUp, Sum : CARDINAL;

   Sum := 0;
   FOR CountUp := 10 TO 15 DO
      Sum := Sum + Donkey[CountUp];
END AddNumbers;

(* ************************************************* GenAddNumbers *)

VAR CountUp, Sum : CARDINAL;

   Sum := 0;
   FOR CountUp := 0 TO HIGH(Donkey) DO
      Sum := Sum + Donkey[CountUp];
END GenAddNumbers;

BEGIN      (* *************************************** main program *)
   FOR Index := 10 TO 15 DO
      SizeOne[Index] := 10;

   FOR Index := 210 TO -8 BY -1 DO
      SizeTwo[Index] := 1;

   WriteString("The sum of the SizeOne numbers is");

   WriteString("Gen sum of the SizeOne numbers is");
   WriteString("Gen sum of the SizeTwo numbers is");

END ArayPass.

The two procedures in this program are identical except for the way the arrays are passed to them. In the first procedure named "AddNumbers", the variable named "Donkey" is passed the array by using the same type which was used to define one of the arrays. The procedure merely adds the values of the elements of the array passed to it and writes the result out to the monitor. The way it is written, it is only capable of adding arrays that are indexed from 10 to 15. Any other array will cause a "type incompatible" error. This is simply called passing an array to the procedure.

The second procedure named "GenAddNumbers" has its input array defined as an "ARRAY OF CARDINAL" with no limits stated. This procedure can add all of the variables in any CARDINAL array regardless of the range of its subscripts. The lower subscript will always be defined as zero within this type of procedure, and the upper limit of the array can be found with the predefined procedure "HIGH". It is used as shown in the example. The first time this procedure is called in the main program, it is called with the variable "SizeOne". In the procedure, the array subscripts for "Donkey" will be 0 through 5. When the variable named "SizeTwo" is the array sent to the procedure, then "Donkey" will have the limits of 0 and 218. The second procedure definition method is therefore more general. This is called passing an "open array" to the procedure.


There will be times when you wish to use the general case for passing a parameter, the "open array". A good example is the procedure named "WriteString" that we have been using in this tutorial. It would be a bit cumbersome if we were only allowed to pass a 10 character string to it each time. Since it can accept a string of any length, it is evidently defined with an "ARRAY OF CHAR" in its header. (We will see in a later chapter that this particular procedure is exactly that, a procedure that someone has thoughtfully programmed for you. You only need to tell the system where it can be found using the IMPORT statement.)

There will likewise be times when you will desire to use the more specific method of definition. If you are using a lot of arrays and have a specific operation that needs to be done to only a few arrays that have a common definition, you would be wise to use this method. The computer could then tell you if you tried to use the procedure on an array that it was not intended for. This is making wise use of the type checking available in the computer.


Load the last file for this chapter, STRINGEX.MOD for an example of using strings in Modula-2. This program is the first program to deviate from the standard library as defined by Niklaus Wirth. When he defined the language, he suggested several library procedures that should be available in every Modula-2 compiler and most compiler writers have followed his suggestions quite closely. He failed to define a standard library for the string handling procedures. There is therefore some freedom for each compiler writer to define the string handling routines in any way he pleases. Most however, have followed at least a resemblance to a standard, so the procedure calls are very similar from compiler to compiler. It may be necessary for you to modify this file to suit your particular compiler. The COMPILER.DOC file on your distribution disk has comments for modifications needed for several compilers, but if yours is not listed, it will be up to you to make the required modifications to the source file.

(* Chapter 6 - Program 6 *)
MODULE StringEx;

(* Note - The "Strings" procedures used here are not standard because
          there is no standard.  You may need to modify some or all
          of the string procedure calls to get them to work.  Consult
          the documentation for your compiler and library.         *)

FROM InOut   IMPORT WriteString, WriteInt, WriteLn;
FROM Strings IMPORT Assign, Concat;

TYPE SevenChar = ARRAY[0..6] OF CHAR;

VAR Horse : ARRAY[0..12] OF CHAR;
    Cow   : ARRAY[0..5] OF CHAR;
    S1    : SevenChar;
    S2    : SevenChar;
    Index : CARDINAL;

(* ******************************************************* Display *)
   WriteString(") - ");
   FOR Index := 0 TO HIGH(Stuff) DO
END Display;

(* ************************************************** main program *)
   Horse := "ABCDEFGHIJKL";           (* Copy constant to variable *)

   Cow := "12345";
   Assign(Cow,Horse);               (* Assign variable to variable *)

   S1 := "Neat";
   S2 := "Things";
   Concat(S1,S2,Horse);       (* Concatenate variables to variable *)
   S1 := S2;                        (* Assign variable to variable *)

   Concat(Horse,Cow,Horse); (* Concatenate one variable to another *)

   Concat(Cow,Horse,Horse);        (* Concatenate to the beginning *)
END StringEx.

A complete description of the libraries and what they are will be given in chapter 8.


The first thing that is different here is the addition of another IMPORT statement in line 10, this one importing procedures from the module named "Strings". This is the module containing the procedures which we will need in this program. A string is an array of type CHAR, each element of the array being capable of storing one character. Thus an array of CHAR type elements is capable of storing a word, a sentence, a paragraph, or even a whole chapter, depending on how big the array is. Using the example on your screen, we will learn how to manipulate text data.

One additional feature of the example program will be found on line 24. In this line the "WriteString" procedure is used in a way we have not used as yet. Instead of having an expression in quotes, it has the name of a variable within its parentheses. It will display whatever characters are stored in the string named "stuff" defined by the "ARRAY OF CHAR". So if we learn how to get a string of characters stored in a variable of type "string", we can display anything on the monitor that we can generate internal to the computer.

According to the definition of Modula-2, a string is an ARRAY OF CHAR with a 0 as a terminator. We will get more familiar with strings as we continue our study.


The first line of the program itself, line 34, contains a string assignment. In this case, we are telling the system to copy the constant "ABCDEFGHIJKL" into the variable named "Horse". The array into which you are copying must begin at index 0 in order for this to work because all character constants are, by definition, started at zero. The variable "Horse", which only contains room for 12 characters will only receive the first 12 characters of the constant. The procedure "Display" is called with Horse as the variable and the variable is displayed between parentheses for clarity of understanding, and the 12 characters of the variable are displayed in their ASCII equivalent. When you finally run this program, compare some of the values to the ASCII table that is included with the DOS documentation that came with your computer.

In line 37 of the program, the constant "12345" is assigned to the variable "Cow". In the next line, the variable "Cow" is assigned to the variable "Horse", and the display procedure is called again. This time, the variable "Cow" is shorter than the destination, so the system has to compensate for the difference. After it transfers the 5 characters to "Horse", it will place a 0 (zero) in the next position to indicate the end of the string. The definition of the string still has 12 places, but there are only 5 places of interest, so the system will consider all places past the 5th as undefined. This time the system only prints out 5 characters in the procedure. The list of ASCII equivalents shows that the other values are still there, the output routine simply stopped when it came to the 0 in the sixth position.

Note that the Assign statement may be different for different compilers because it is not a part of the Modula-2 definition by Niclaus Wirth.


Concatenation is simply putting two strings together to make up one bigger string. Beginning in line 41, two new string variables are defined, "S1" and "S2", then the two new variables are concatenated together and assigned to our old favorite variable named "Horse". The variable "Horse" should now contain the silly expression "NeatThings", and when you run the program, you will find that it does. It also has a 0 in character position 11 now to indicate the end of the string. Line 47 concatenates "Horse" to "Cow" and stores the result in "Horse", but since the expression is now too long, part of it will get truncated and simply thrown away. Finally, "Cow" is concatenated to "Horse", and the result stored back into "Horse". This has the effect of shifting the prior contents of "Horse" right and adding the characters stored in "Cow" to the beginning. Line 45 is an example of a string assignment. This is only possible because they are of the same TYPE. The variable "Cow" has a different TYPE so can't be assigned to either of these two variables. Note that the TYPE does not have to start at zero for this to work.

Note that even though "Horse" was the only variable used in the calls to "Display", any of the other strings could have been used also. This is the topic of the fourth programming exercise below.

Compile and run the program and see if it really does do all that it should do as described above, keeping in mind that you may have to modify the file to accommodate your particular compiler.


1. Write a program to store the CARDINAL values 201 to 212 in an array then display them on the monitor.

2. Write a program to store a 10 by 10 array containing the products of the indices, therefore a multiplication table. Display the matrix on the monitor.

3. Modify the program in 2 above to include a constant so that by simply changing the constant, the size of the matrix and the range of the table will be changed.

4. Modify the program named STRINGEX.MOD to include calls to "Display" with each of the string variables at the end of the program.

Chapter 7 - Overall Program Construction

We have pretty well covered the topic of how to put all the parts together to build up a program. In this chapter we will go over the whole process in order to clear up any loose ends and have the entire process in one place. There is nothing magic about the way the various pieces fit together but the rules must be followed in order to build a usable program.

Load and display the program named OVERPROG.MOD for the first look at the overall structure of the Modula-2 program. It would be well for you to keep in mind that there is a major category that we have not even hinted at yet, the issue of modules. They will be covered in Part III of this tutorial, and although they are very important, you can begin writing meaningful programs before you even hear what modules are or how they are used.

(* Chapter 7 - Program 1 *)
MODULE OverProg;    (* Overall program construction example *)

FROM InOut IMPORT WriteString, WriteLn;

     PROCEDURE Proc1;
       WriteString("Procedure 1");
     END Proc1;

     PROCEDURE Proc2;
          PROCEDURE Proc3;
            WriteString("Procedure 3");
          END Proc3;

          PROCEDURE Proc4;
               PROCEDURE Proc5;
                 WriteString("Procedure 5");
               END Proc5;
            WriteString("Procedure 4");
          END Proc4;
       WriteString("Procedure 2");
     END Proc2;

  WriteString("Main Program");
END OverProg.


The program on display contains several levels of nested procedures as an illustration for you. The main program has lines 1 through 37 as its declaration part, and lines 38 through 43 as its statement part. Since the procedure definitions actually define the procedures called for by the main program, they correctly belong in the declaration part of the program. Only two of the procedures are actually callable by the main program, "Proc1", and "Proc2". The procedure "Proc1" is a simple procedure, but "Proc2" has additional procedures in its declaration part.

Procedure "Proc2" contains a declaration part in lines 13 through 30, and a statement part in lines 31 through 36. Its declaration part contains two procedures, "Proc3" and "Proc4". The nesting is carried one step farther in "Proc4" which contains the procedure "Proc5" in its declaration part. Procedures can be nested to whatever level desired according to the definition of Modula-2.


It is important for you to clearly understand which procedure can call which other procedures. A procedure can call any procedure on the same level as itself provided that both have the same parentage, or any procedure that is included in its own declaration part at the level of its own declaration part. For example, the main program can only call "Proc1", and "Proc2". The others are nested within "Proc2" and are not available to the main program. Likewise the statement part of "Proc2" can call "Proc1", because it is on the same level, and "Proc3" and "Proc4", because they are within its declaration part. The procedure "Proc5" can only be called by "Proc4", because no other procedure is at its level. Note that if another triple nesting were included in "Proc1", its third level procedure could not be called by "Proc5" because they would not have the same parentage.

Nested procedures can be very useful when you wish to use a procedure that you don't want any other part of the program to be able to access or even see. A private procedure can therefore be written with no concern that the name may clash with some other part of the program and cause undesirable effects.

The important thing to gain from this program is that nesting is possible and can be very useful, and the definition of a procedure is the same as that of the main program. This means that procedures can be nested within procedures in any way that aids in designing the program.

Compile and run this program and see if you understand the output from it.


Load MOREPROG.MOD, for examples of where you can put the other definitions in the declaration part of the program and the procedures. This is a repeat of the last program with CONST, TYPE, and VAR declarations added in every place where it is legal to put them. This is done as an example to you of where they can be put, so no explanation of details will be given. Some time spent studying this program should aid you in understanding even better the overall program construction problem.

(* Chapter 7 - Program 2 *)
MODULE MoreProg;   (* More program construction examples *)

FROM InOut IMPORT WriteString, WriteLn;

CONST MainC = 27;
VAR   MainV : MainT;

     PROCEDURE Proc1;
     CONST Proc1C = 33;
     TYPE  Proc1T = ARRAY[-23..-15] OF CHAR;
     VAR   Proc1V : MainT;
           Proc11 : Proc1T;
       WriteString("Procedure 1");
     END Proc1;

     PROCEDURE Proc2;
     CONST Proc2C = 22;
     TYPE  Proc2T = ARRAY[3..5],[-4..0] OF BOOLEAN;
     VAR   Proc2V : MainT;
           Proc21 : Proc2T;
          PROCEDURE Proc3;
          CONST Proc3C = -234;
          TYPE  Proc3T = ARRAY[12..13] OF MainT;
          VAR   Proc3V : MainT;
                Proc31 : Proc2T;
                Proc32 : Proc3T;
            WriteString("Procedure 3");
          END Proc3;

          PROCEDURE Proc4;
          CONST Proc4C = 111;
          TYPE  Proc4T = CARDINAL;
          VAR   Proc4V : MainT;
                Proc41 : Proc2T;
                Proc42 : Proc4T;
               PROCEDURE Proc5;
               CONST Proc5C = "A";
               TYPE  Proc5T = ARRAY[22..222] OF CHAR;
               VAR   Proc5V : MainT;
                     Proc51 : Proc2T;
                     Proc52 : Proc4T;
                     Proc53 : Proc5T;
                 WriteString("Procedure 5");
               END Proc5;
            WriteString("Procedure 4");
          END Proc4;
       WriteString("Procedure 2");
     END Proc2;

  WriteString("Main Program");
END MoreProg.


Load the program LASTPROG.MOD for an example of how the various fields can be ordered in the declaration part of the program. Notice that there are 2 procedures, two CONST's, two TYPE's, and two VAR's defined, but they are defined in a seemingly random order. The order is random and was done only to illustrate to you that the order doesn't matter as long as everything is defined before it is used.

(* Chapter 7 - Program 3 *)
MODULE LastProg;

FROM InOut IMPORT WriteString, WriteLn;

   END Dummy;

TYPE Stuff = ARRAY[34..55] OF CHAR;

   END Smart;

CONST Number = 120;
TYPE  TypeOf = ARRAY[1..Number] OF Stuff;
CONST Neater = -345;
VAR   Count23 : TypeOf;
      Counter : INTEGER;

   WriteString("This is really a stupid program.");
END LastProg.

In only one case does the order matter. The compiler is very picky about where the IMPORT list goes because the Modula-2 language definition requires it to be first. In addition, the EXPORT list must immediately follow the IMPORT list. We will cover both of these in detail later, for now simply remember that the order of all declarations can come in random order as long as they follow the IMPORT/EXPORT lists and come before the statement part of the program.


1. Using the program OVERPROG, add some calls to illegal places to see what messages the compiler displays.

2. Using the program MOREPROG, add some illegal variable references to see what messages the compiler displays.

Chapter 8 - Input/Output


Load and display the file named SIMPLOUT.MOD for an example of the simple output functions. This program is limited to writing only to the monitor but we will get to files and printer output shortly. We must first establish some basic principles for use with library procedures.

(* Chapter 8 - Program 1 *)
MODULE SimplOut;

FROM InOut IMPORT WriteString, WriteLn;         (* unqualified *)
IMPORT InOut;         (* This imports every procedure in InOut *)
IMPORT Terminal;   (* This imports every procedure in Terminal *)


   WriteString("This is from InOut, ");
   InOut.WriteString("and so is this.");

   Terminal.WriteString("This is from Terminal, ");
   Terminal.WriteString('and so is this.');

   FOR Index := 1 TO 10 DO
END SimplOut.

The first line of the declaration part of the program imports our two familiar procedures "WriteString" and "WriteLn" in the same manner we are used to. The next line imports every procedure in "InOut" and makes them available for use in the program without specifically naming each one in the IMPORT list. The third line imports every procedure from "Terminal" so that they too are available for our use. The procedures that are imported explicitly can be used in exactly the same manner that we have been using them all along, simply name the procedure with any arguments they use. The others can only be used with a "qualifier" that tells which library module they come from.

An example is the easiest way to describe their use so refer to the program before you. Line 11 uses the explicitly defined procedure from "InOut", line 12 uses the same procedure from "InOut", and line 15 uses the procedure of the same name from "Terminal". Line 11 uses the unqualified procedure call from "InOut", and lines 12 and 15 use the qualified method of calling the procedures from both library modules.

In this case, the two procedures do the same thing, but it is not required that procedures with the same name do the same thing. By adding the library module name to the front of the procedure name with a period between them, we tell the system which of the two procedures we wish to use. If we tried to explicitly import both "WriteString" procedures we would get a compile error, so this is the way to use the same name twice.


What I have been calling a library module is more properly termed a "module" and is the biggest benefit that Modula-2 enjoys over other programming languages. This is the quality that gives Modula-2 the ability to have separately compiled modules, because a module is a compilation unit. When you get to Part III of this tutorial, you will learn how to write your own modules containing your own favorite procedures, and call them in any program in the same manner that you have been calling the procedures provided by your compiler writer.

None of the procedures you have been importing are part of the Modula-2 language, they are extensions to the language provided for you by your compiler writer. Since they are not standard parts of the language, they may vary from compiler to compiler. For that reason, I have tried to use those defined by Niklaus Wirth in his definition of the language, and no others.


This would be a good place for you to stop and spend some time reading your reference manual. Look up the section in your manual that is probably called the "Library" and read through some of the details given there. You will find that there are many things listed there that you will not understand at this point, but you will also find many things there that you do understand. Each module will have a number of procedures that are "exported" so that you can "import" them and use them. Each procedure will have a definition of what arguments are required in order to use it. Most of these definitions should be understandable to you. One thing you will find is that only the "PROCEDURE procname;" is given along with the arguments, with the actual code of the procedure omitted. We will study about this in "Part III" also. The part that is shown is the "DEFINITION MODULE" which only gives the calling requirements. The "IMPLEMENTATION MODULE" which gives the actual program code of the procedure is usually not given by compiler writers.

As you study the library modules, you will find procedures to handle strings, variables and conversions between the two. You will find "mouse" drivers, "BIOS" calls to the inner workings of your operating system, and many other kinds of procedures. All of these procedures are available for you to use in your programs. They have been written, debugged, and documented for your use once you learn to use them. In addition, you will have the ability to add to this list by creating your own modules containing your own procedures.


Notice that in lines 13, 17, and 22, three different ways are used to call "WriteLn", even though there are actually only two procedures (that happen to do the same thing). A little time spent here will be time well spent in preparing for the next few programs. When you think you understand this program, compile and run it.


Load the program named SIMPLIN.MOD for our first example of a program with some data input procedures. In every program we have run so far in this tutorial, all data has been stored right in the program statements. It would be a very sad computer that did not have the ability to read variable data in from the keyboard and files. This program is our first that can read from an external device, and it will be limited to only the keyboard.

(* Chapter 8 - Program 2 *)

FROM InOut IMPORT WriteString, WriteCard, WriteLn, Write,
                  ReadString, ReadCard, Read, EOL;

VAR Count, Number : CARDINAL;
    List          : ARRAY[1..6] OF CARDINAL;
    StringOfData  : ARRAY[1..80] OF CHAR;
    Alpha         : CHAR;

                          (* Example of reading in a word at a time *)
   WriteString("Input three words of information.");
   FOR Count := 1 TO 3 DO                        (* Read 3 words in *)
                                    (* Example of character reading *)
   WriteString("Input 50 characters.");
   FOR Count := 1 TO 50 DO
                         (* Example of reading in a line at a time. *)
   WriteString("Input three lines of information.");
   FOR Count := 1 TO 3 DO                      (* count three lines *)
      Number := 1;
      REPEAT                (* repeat until an end-of-line is found *)
         IF Alpha <> EOL THEN
            StringOfData[Number] := Alpha;
            Number := Number + 1;
      UNTIL Alpha = EOL;
      StringOfData[Number] := 0C;        (* End of string indicator *)
                          (* Example of reading CARDINAL numbers in *)
   WriteString("Enter 6 CARDINAL numbers.");
   FOR Count := 1 TO 6 DO
      WriteLn;                (* New line for separation of numbers *)
   FOR Count := 1 TO 6 DO             (* Now, write the numbers out *)

END SimplIn.

This program is broken up into four groups of statements, each illustrating some aspect of reading data from the keyboard. This could have been four separate files but it will be easier to compile and run one file.

Beginning with line 14 we have an example of the "ReadString" procedure which reads characters until it receives a space, a tab, a return, or some other nonprintable character. This loop will read three words on one line, one word on each of three lines, or any combination to get three words of groups of printable ASCII characters. After each word or group is read, it is simply "printed" to the monitor for your inspection.


The next group of statements is a loop in which 50 ASCII characters are read in and immediately echoed out to the monitor. It should be evident to you that the characters are read one at a time, and since the same variable is used for each character, they are not stored or saved in any way. In actual practice, the characters would be stored for whatever purpose you intend to use them for. When you run this part of the program, it will seem like the computer is simply acting like a word processor, echoing your input back to the monitor.


The next section, beginning in line 32, reads in a full line before writing it out to the monitor. In this program we are introduced to the "EOL" which is a constant defined by the system for our use. It must be imported from "InOut" just like the procedures are, and it is a constant that is equal to that ASCII value that is returned when we hit the "return" key. It is therefore equal to the End-Of-Line character, and that is how it got its name. If we compare the input character to it, we can determine when we get to the End-Of-Line. That is exactly what this loop does. It continues to read characters until we find an EOL, then it terminates the input loop and displays the line of data. Notice that this time we do not simply read the data and ignore it but instead add it character by character to the ARRAY named "StringOfData". Of course, the next time through the loop we overwrite it. The careful student will also notice that, in line 45 we wrote a zero character in the character of the line just past the end of the line. The zero is to indicate the end-of-string for the string handling procedures. This portion of the program is easy, but will require a little time on your part to completely dissect it.


Beginning in line 51, we have an example of reading 6 CARDINAL numbers in a loop. The procedure "ReadCard" will, when invoked by your program, read as many digits as you give it. When it reads any character other than a 0 through 9, it will terminate and return the number to your calling program. Notice that this time all 6 numbers are read in, stored, and when all are in, they are all displayed on one line. This should be easy for you to decipher.


There is no program that you have studied here that is as important for you to compile and run as this one is. You should spend considerable time running this program and comparing the results with the listing. Enter some invalid data when you are running the "ReadCard" portion of it to see what it does. When you are running the "line at a time" portion, try to enter more than 80 characters to see what it will do with it. This is a good point for you to learn what happens when errors occur. After you understand what this program does, we will proceed to file input and output.


Load and display the file named FILEIO.MOD for your first file reading and writing. The library module named "InOut" has the ability to either read and write from/to the keyboard and monitor, or to read and write from/to files. The program before you redirects the input and output to files for an illustration of how to do it.

(* Chapter 8 - Program 3 *)

FROM InOut IMPORT WriteString, WriteInt, WriteLn, Write, Read,
                  OpenInput, OpenOutput, CloseInput, CloseOutput,

IMPORT Terminal;                 (* This is used for monitor output *)
                                 (* and InOut is used for the file  *)
                                 (* input and output.               *)

VAR Character : CHAR;

   REPEAT                                    (* open the input file *)
      Terminal.WriteString("Enter Input filename  - ");
   UNTIL Done;                      (* Quit when open is successful *)

   REPEAT                                   (* open the output file *)
      Terminal.WriteString("Enter Output filename - ");
   UNTIL Done;                  (* quit when the open is successful *)

   REPEAT                (* character read/write loop - quit at EOF *)
      IF Done THEN                           (* Done = FALSE at EOF *)
   UNTIL NOT Done;


Line 16 requests the operator, namely you, to enter a filename to be used for input. There is nothing different about this statement than the others you have been using. The next line requests the system to open a file for inputting, and part of the procedure "OpenInput" is to go to the keyboard waiting for the filename to be typed in. So the message in line 16 is in preparation for what we know will happen in line 17. Whatever filename is typed in is opened for reading if it is found on the disk. The "MOD" in the parentheses is a default extension supplied, (this can be any extension you desire). If no extension is supplied by the operator, and if the filename does not have a "." following it, ".MOD" will be added to the filename. If the system can find the requested filename.extension, the "Done" flag is made TRUE and we can test it. In this example, if the flag is returned FALSE, we ask the operator to try again until he finally inputs a filename that exists on the default disk/directory.


Once again, in line 21, we request a filename for output anticipating the operation of the "OpenOutput" in line 22. Line 22 waits for a keyboard input of a filename and if the filename entered has no extension, it adds the extension ".DOG" and attempts to open the file for writing. When you input the filename, adding a "." to the end of the filename will prevent the extension being added. If the Filename.extension does not exist, it will be created for you. If it does exist, it's contents will be erased.

It is nearly assured that the file will be created and the "Done" flag will be supplied as TRUE, but it would be good practice to check the flag anyway. It will be apparent when we get to the program on printer output, that it is impossible to open a file with certain names, one being "PRN", because the name is reserved for printer identification and the "Done" flag will be returned FALSE.


Anytime you use this technique to open a file for writing, any procedure from InOut will now be redirected to that file. Anytime you use this technique to open a file for reading, any procedure from InOut will access the file named instead of the keyboard. In addition, the library module named "RealInOut" will also be redirected with "InOut". Any time you read or write, instead of using the keyboard and monitor, the input and output files will be used. The input and output will be the same except for where it goes to and comes from, and it is possible to only open one and leave the other intact. Thus input can be from a file, and output can still go to the monitor.

When I/O is redirected, the module "Terminal" is still available for use with the monitor and keyboard as I/O using this module can not be redirected. The module named "Terminal" does not have the flexibility of input and output that is found in "InOut" so it is a little more difficult to use.

There is a major drawback when using "InOut" with the I/O redirected. You are limited to one file for input and one file for output at one time. Finally, this method cannot be used to open a "fixed" or prenamed file, since it always surveys the keyboard for the filename. It will probably come as no surprise to you that all of these limitations will be overcome with another method given in the next two programs.

The program itself should be easy to follow, once you realize that the flag named "Done" returns TRUE when a valid character is found following a "Read", and FALSE when an End-Of-File (EOF) is detected. The "Done" flag is set up following each operation so its use is dictated by which procedure was called last. The program simply copies all characters from one file to another. When completed, the two procedures named "CloseInput" and "CloseOutput" are called to do just that, to close the files and once again make the I/O available to the keyboard and monitor. In this case, however, we immediately terminate the program without taking advantage of the return to normal.

Compile and run this program, being careful not to give it the name of an existing file for output, or it will overwrite the old data in the file and copy new data into it. That is the reason for the extension "DOG". Few people will have a file with that extension. For input, use the present filename (FILEIO.MOD), for output, use "STUFF", "STUFF.", and "STUFF.STU", observing the resulting new filename each time.


Load and display the file named VARYFILE.MOD for an example using the complete "FileSystem" module. As stated earlier, Modula-2 does not have any input/output methods defined as part of the language. This is because the I/O available on computers is so diverse, there would be no way of defining a method that could be used on all computers. To eliminate the problem, Niklaus Wirth simply defined no I/O as part of the language, but he did suggest a few standard modules to perform the basic I/O tasks. Since they are only suggestions, compiler writers are not constrained to follow them, but in the interest of portability, most will. A very limited subset of all of the procedures are the only ones that will be used in the tutorial portion of this course. (A few other procedures will be used in the example programs given in those chapters.) It will be up to you to see that the procedures are in order with your compiler, and where they differ, to modify them. A few notes are available for your assistance in the COMPILER.DOC file on your distribution disk for those compilers available at the time of release of this tutorial.

(* Chapter 8 - Program 4 *)
MODULE VaryFile;

FROM FileSystem IMPORT Lookup, Close, File, Response, ReadChar;
FROM InOut      IMPORT Write, WriteString, ReadString, WriteLn;

VAR  NameOfFile : ARRAY[1..15] OF CHAR;
     InFile     : File;
     Character  : CHAR;

   REPEAT                  (* repeat until a good filename is found *)
      WriteString("Enter name of file to display ---> ");
   UNTIL InFile.res = done;                  (* good filename found *)

   REPEAT       (* character read/display loop - quit at InFile.eof *)
      IF NOT InFile.eof THEN
   UNTIL InFile.eof;                      (* quit when eof is found *)

END VaryFile.


This time we IMPORT several procedures from the library module named "FileSystem" for I/O use. This time, we ask for the input filename and store it internally in a string variable. This implies that we can also define the filename as a constant that is carried in the program, making it possible to use a certain preprogrammed filename for input. We use the procedure "Lookup" to open the file. This procedure uses three arguments within the parentheses, the first being the symbolic filename which is a record of information about the file. (We will come to records later, don't worry too much about it at this point.) The second

argument is the name of the file on disk we wish to access, and the third argument is a boolean variable or constant. If it is TRUE, and the file name is not found, a new file of that name will be created. If it is FALSE, and the file is not found, a new file will not be created, and the record variable "InFile.res" will return the value "notdone". (That refers to one variable named "res" which is a part of the record "InFile".)

Note that the variable "InFile", is a record composed of many parts, but for the immediate future we only need to be concerned with its definition. It is defined as a variable of type "File" which is imported from the module named "FileSystem". Until you study the lesson in this tutorial on records, simply copy the method used here for file Input/Output.

Once the file is opened, you can use any of the procedures included in the "FileSystem" module, being careful to follow the rules given in your library documentation. The remainder of the program should be self- explanatory and will be left to your inspection. With this example in hand, spend some time studying your "FileSystem" module to become familiar with it, then compile the program and run it to observe its operation.


Load and display the file named PRINTFLE.MOD for an example program that uses 4 files at once, and still writes to the monitor. This program is very similar to the last in that it opens one file for reading, but it opens three files for writing. Each of the four files has its own identifier, a record of type "File", and each has its own filename. The three output files are firmly fixed to certain filenames, rather than ask the operator for names, and the third filename is a very special name, "PRN". This is not a file but is the access to the printer. Anything written to this file will go to your line printer, so you should turn your printer on in anticipation of running it. Your compiler may also allow a few other names such as "LPT0", "LPT1", etc, and there may be other names reserved for serial I/O such as to talk to a modem, a joystick, etc. You will need to consult your compiler documentation for a complete list of special names.

(* Chapter 8 - Program 5 *)
MODULE PrintFle;

FROM FileSystem IMPORT Lookup, Close, File, Response, ReadChar,
FROM InOut      IMPORT Write, WriteString, ReadString, WriteLn;

VAR  NameOfFile : ARRAY[1..15] OF CHAR;
     InFile     : File;
     OutFile    : File;
     CapFile    : File;
     PrtFile    : File;
     Character  : CHAR;

   REPEAT                  (* repeat until a good filename is found *)
      WriteString("Enter name of file to display,");
      WriteString(" store, and print ---> ");
   UNTIL InFile.res = done;                  (* good filename found *)


   REPEAT       (* character read/display loop - quit at InFile.eof *)
      IF NOT InFile.eof THEN
   UNTIL InFile.eof;                      (* quit when eof is found *)

END PrintFle.

The program itself is very simple and similar to the last one. A character is read from the input file, and output to the three output files and to the monitor. In the case of "CapFile", the character is capitalized before it is output simply to indicate to you that the files are indeed different. Study it until you understand it, then compile and run it. Look at the contents of the new files to see if they are correct.


There are many more things that you can do with the "FileSystem" module. It is possible to open a file, begin reading until you come to a selected position, and change to a write file to overwrite some of the data with new data. You can write to a file, change it to a read file, reset it to the beginning, and read the data back out. You can rename a file, or delete it. It will be up to you to study the documentation for your "FileSystem" module, and learn how to use it effectively.


With the completion of this chapter, you have arrived at a very special point in your study of Modula-2. Many people arrive at this point in a language and quit studying, preferring to use the language in a somewhat limited sense rather than to go on and learn the advanced topics. If your needs are few, you can quit here also and be well assured that you can write many programs with Modula-2. In fact there will be very few times when you cannot do all that you wish to do. However, if you choose to go on to the advanced topics, you will find that some of the programming chores will be greatly simplified.

Whether you decide to go on to the advanced topics or not, it would be wise for you to stop at this point and begin using what you have learned to actually write some programs for your own personal use. Everybody has need occasionally for a program to do some sort of translation of data in a text file for example. Write programs to do some data shuffling from file to file changing the format in some way. You should be able to think up several programs that you would find useful.

Spend some time studying and running the programs in the next chapter, then modify them to suit your needs, building up a few utilities for your software collection. The best way to learn to program is to program. You have all of the tools you need to get started, so you would do well to get started. Adding some programming experience will be a big help if you decide to continue your study into the advanced features of Modula-2.

Chapter 9 - Example programs

The programs included in this chapter are intended to be illustrations to you in how to write a complete program. The programs are meant to be useful to you either as an example of how to do some operation or as utility programs for your general use.

TIMEDATE - Get Time and Date

MODULE TimeDate;

(* Note - DOSCALL calls interrupt 21(hex) = 33(dec) which is the   *)
(*        general purpose BIOS interrupt.  It is used for many     *)
(*        operations on the disks, and other peripherals.  See     *)
(*        your DOS manual for details.  Some DOS manuals don't     *)
(*        have any information on this so your next best bet is    *)
(*        Peter Norton's book "Programmers Guide to the IBM-PC.    *)

FROM InOut IMPORT WriteString, WriteCard, WriteLn;

VAR MonthDay, Year, Month, Day        : CARDINAL;
    HourMinute, SecondMillisec        : CARDINAL;
    Hour, Minute, Second, Millisecond : CARDINAL;
    Index, Count, Stuff               : CARDINAL;

   FOR Index := 1 TO 15 DO

      DOSCALL(2AH,Year,MonthDay);    (* Year is alone in a word    *)
      Month := MonthDay DIV 256;     (* Month is in top half       *)
      Day := MonthDay MOD 256;       (* Day is in bottom half      *)

      Hour := HourMinute DIV 256;
      Minute := HourMinute MOD 256;
      Second := SecondMillisec DIV 256;
      Millisecond := 10*(SecondMillisec MOD 256); (* actually this *)
                                    (* is in hundredths of seconds *)

      WriteString("The time is ");
      WriteString("   ");

               (* The following loop takes about one second to  *)
               (* finish its full count on an IBM-PC at normal  *)
               (* speed.  It may vary in time for your system.  *)

      FOR Count := 1 TO 13300 DO
         Stuff := 32000 DIV Count;
END TimeDate.

This program calls one of the DOS functions to get the current time and date. They are input as variables and can be printed or displayed in any format you desire. Your particular compiler may use a different format because there is no standard in Modula-2. This is one of those areas that will probably deviate from compiler to compiler. If you study your documentation that came with your compiler, you will find many other calls of this type described. This program is meant to be an illustration of how to use this particular call.

AREAS - Calculate Areas

(* This program is actually a very silly program with little or    *)
(* no utilitarian value.  It is valuable as an illustration of a   *)
(* method of implementing a menu for selection purposes.  Notice   *)
(* when you run it, that the response to your input is immediate   *)
(* No "return" is required.                                        *)


FROM InOut IMPORT Read, WriteString, Write, WriteLn;
FROM RealInOut IMPORT WriteReal, ReadReal;

VAR InChar, CapInChar : CHAR;

(* ************************************************** AreaOfSquare *)
VAR Length, Area : REAL;
   WriteString("Square    Enter length of a side ");
   Area := Length * Length;
   WriteString("The area is ");
END AreaOfSquare;

(* *********************************************** AreaOfRectangle *)
PROCEDURE AreaOfRectangle;
VAR Width, Height, Area : REAL;
   WriteString("Rectangle    Enter Width ");
   WriteString("Enter Height ");
   Area := Width * Height;
   WriteString("      The area is ");
END AreaOfRectangle;

(* ************************************************ AreaOfTriangle *)
PROCEDURE AreaOfTriangle;
VAR Base, Height, Area : REAL;
   WriteString("Triangle    Enter base ");
   WriteString("Enter height ");
   Area := 0.5 * Base * Height;
   WriteString("      The area is ");
END AreaOfTriangle;

(* ************************************************** AreaOfCIrcle *)
VAR Radius, Area : REAL;
   WriteString("Circle      Enter Radius ");
   Area := 3.141592 * Radius * Radius;
   WriteString("The area is ");
END AreaOfCircle;

(* ************************************************** Main Program *)
      WriteString("You only need to input the first letter ");
      WriteString("of the selection.");
      WriteString("Select shape; Square Rectangle Triangle ");
      WriteString("Circle Quit");
      WriteString("Requested shape is ");
      CapInChar := CAP(InChar);           (* Get capital of letter *)
      CASE CapInChar OF
        'S' : AreaOfSquare; |
        'R' : AreaOfRectangle; |
        'T' : AreaOfTriangle; |
        'C' : AreaOfCircle; |
        'Q' : WriteString("Quit    Return to DOS");
         WriteString(" Invalid Character ");
   UNTIL CapInChar = 'Q';
END Areas.

This program is intended to be an illustration for you of how to build up a larger program than any other that we have examined up to this point. Notice that the main program is simply one CASE statement that calls all of the other procedures. It would be very simple to include the code from each procedure right in the CASE statement and have no procedure calls, but it would make the program very difficult to understand. The way this example is coded, the code is very easy to understand. After you understand the main program, it is a very simple matter to visit each procedure to see exactly what they do.

Notice how the menu works in this program. It reads one keystroke and responds immediately making it a very simple program to use.

PC - Printer Control


(* The codes in this program are for an EPSON RX-80.  You may have *)
(* to adjust the codes for your printer.                           *)

FROM InOut IMPORT WriteString, WriteLn, Read, Write;
FROM FileSystem IMPORT Lookup, WriteChar, Close, File;

VAR InputChar, Char0, Char1 : CHAR;
    PrintFile               : File;

   WriteString("F Formfeed");                    WriteLn;
   WriteString("C/N Compressed/Normal");         WriteLn;
   WriteString("D/S DoubleStrike/SingleStrike"); WriteLn;
   WriteString("E/R Emphasized/Regular");        WriteLn;
   WriteString("Enter Selection --> ");
   InputChar := CAP(InputChar);

                          (* Character input - now output the code *)

   CASE InputChar OF
    'F' : Char0 := 14C;      (* Formfeed *)
          Char1 := 0C;   |
    'C' : Char0 := 17C;      (* Compressed mode *)
          Char1 := 0C;   |
    'N' : Char0 := 22C;      (* Normal width *)
          Char1 := 0C;   |
    'D' : Char0 := 33C;      (* Double Strike - esc-'G' *)
          Char1 := 107C; |
    'S' : Char0 := 33C;      (* Single Strike - esc-'H' *)
          Char1 := 110C; |
    'E' : Char0 := 33C;      (* Emphasized Print - esc-'E' *)
          Char1 := 105C; |
    'R' : Char0 := 33C;      (* Emphasized Off - esc-'@' *)
          Char1 := 100C;
      WriteString("Invalid Character.");

   Lookup(PrintFile,"PRN",TRUE);    (* Open print file *)
   IF Char1 > 0C THEN


This is a very useful program that you can use to control your printer. It is specifically set up for an Epson RX-80, but you can modify the control characters to set up your printer to whatever mode you desire. To use the program, you call the program and supply a single letter according to the displayed menu, and the program will send the character or characters to the printer to select the enhanced, compressed, or whatever mode you desire. If your printer is located physically remote from you, you can use this program to send a formfeed to the printer by selecting the F option. If you have some longer control sequences to send, you may want to store the values in a string and use a loop to output the data until you come to an 0C character.

LIST - List Program File

MODULE List;   (* Program to list Modula-2 source files with page  *)
               (* numbers and line numbers.                        *)

FROM FileSystem IMPORT Lookup, Close, File, ReadChar, Response,
FROM Conversions IMPORT ConvertCardinal;
FROM TimeDate IMPORT GetTime, Time;

TYPE BigString   = ARRAY[1..80] OF CHAR;
     SmallString = ARRAY[1..25] OF CHAR;

VAR InFile     : File;          (* The Input File record            *)
    Printer    : File;          (* The Printer File record          *)
    NameOfFile : SmallString;   (* Storage for the filename         *)
    InputLine  : BigString;     (* The Input line of characters     *)
    LineNumber : CARDINAL;      (* The current line number          *)
    LinesOnPage : CARDINAL;     (* Number of Lines on this page     *)
    PageNumber  : CARDINAL;     (* Page Number                      *)
    Index       : CARDINAL;     (* Used locally in several proc's   *)
    Year,Day,Month     : CARDINAL;
    Hour,Minute,Second : CARDINAL;
    GoodFile    : BOOLEAN;

(* ************************************************ WriteCharString *)
(* Since there is no WriteString procedure in the FileSystem        *)
(* module, this procedure does what it would do.  It outputs a      *)
(* string until it comes to the end of it or until it comes to a    *)
(* character 0.                                                     *)
PROCEDURE WriteCharString(CharString : ARRAY OF CHAR);
   Index := 0;
      IF Index > HIGH(CharString) THEN EXIT END; (* Max = 80 chars  *)
      IF CharString[Index] = 0C THEN EXIT END;   (* If a 0C is found*)
END WriteCharString;

(* ************************************************* WriteLnPrinter *)
(* Since there is no WriteLn procedure in the FileSystem module,    *)
(* procedure does its job.                                          *)
PROCEDURE WriteLnPrinter;
END WriteLnPrinter;

(* ************************************************* GetFileAndOpen *)
(* This procedure requests the filename, receives it, and opens the *)
(* source file for reading and printing.  It loops until a valid    *)
(* filename is found.                                               *)
   InOut.WriteString("Name of file to print ---> ");
   IF InFile.res = done THEN
      GoodFile := TRUE;
      Lookup(Printer,"PRN",TRUE);            (* open printer as a file *)
      GoodFile := FALSE;
      InOut.WriteString("   File doesn't exist");
END GetFileAndOpen;

(* ***************************************************** Initialize *)
(* This procedure initializes some of the counters.                 *)
PROCEDURE Initialize;
VAR PackedTime : Time;
   LineNumber := 1;
   LinesOnPage := 0;
   PageNumber := 1;
   Day := MOD 32;
   Month := DIV 32;
   Month := Month MOD 16;
   Year := 1900 + DIV 512;
   Hour := PackedTime.minute DIV 60;
   Minute := PackedTime.minute MOD 60;
   Second := PackedTime.millisec DIV 1000;
END Initialize;

(* *********************************************** PrintTimeAndDate *)
(* This procedure prints the time and date at the top of every page *)
PROCEDURE PrintTimeAndDate;
VAR OutChars : ARRAY[0..4] OF CHAR;
   WriteCharString("      ");
   WriteCharString("  ");
END PrintTimeAndDate;

(* *************************************************** OutputHeader *)
(* This procedure prints the filename at the top of each page along *)
(* with the page number.                                            *)
PROCEDURE OutputHeader;
VAR PageOut : ARRAY[1..4] OF CHAR;
   WriteCharString("   Filename --> ");
   WriteCharString("           ");
   WriteCharString("   Page");
END OutputHeader;

(* *************************************************** OutputFooter *)
(* This procedure outputs 8 blank lines at the bottom of each page. *)
PROCEDURE OutputFooter;
   FOR Index := 1 TO 8 DO
END OutputFooter;

(* ******************************************************* GetALine *)
(* This procedure inputs a line from the source file.  It quits when*)
(* it finds an end-of-line, an end-of-file, or after it gets 80     *)
(* characters.                                                      *)
VAR LocalChar : CHAR;
   FOR Index := 1 TO 80 DO      (* clear the input area so that the *)
      InputLine[Index] := 0C;   (* search for 0C will work.         *)

   Index := 1;
      IF InFile.eof THEN EXIT END;
      InputLine[Index] := LocalChar;
      IF Index = 81 THEN EXIT END;
END GetALine;

(* ***************************************************** OutputLine *)
(* Output a line of test with the line number in front of it, after *)
(* checking to see if the page is full.                             *)
VAR Count       : CARDINAL;
    CardOutArea : ARRAY[1..8] OF CHAR;
   IF LinesOnPage > 56 THEN
      LinesOnPage := 1;
   WriteCharString("  ");
END OutputLine;

(* *************************************************** SpacePaperUp *)
(* At the end of the listing, space the paper up so that a new page *)
(* is ready for the next listing.                                   *)
   Count := 64 - LinesOnPage;
   FOR Index := 1 TO Count DO
END SpacePaperUp;

(* *************************************************** Main Program *)
(* This is nothing more than a big loop.  It needs no comment.      *)
   IF GoodFile THEN
         IF NOT InFile.eof THEN
      UNTIL InFile.eof;
END List.

If you ran the batch file named LISTALL as suggested at the beginning of this tutorial to print out all of the source files, you have already used this program. It is the program that will list any ASCII file, adding line numbers, page numbers, and the date and time, on the printer. It is specifically designed to be a program listing utility. The operation is very simple, and you should have no trouble in understanding this program or what it does.

Additional programs will be given at the end of Part III for your information. You will no doubt find additional example programs in various books and periodicals and it would be to your advantage to to spend some time studying them as illustrations of both good and bad practices.

Chapter 10 - Scalars, subranges, and Sets


In order to understand the material in this chapter, you should have a fairly good understanding of the material in Part I of this tutorial.

A scalar, also called an enumerated type, is a list of values which a variable of that type may assume. Look at the file named ENTYPES.MOD for an example of some scalars. The first TYPE declaration defines "Days" as being a type which can take on any one of seven values. Since, within the VAR declaration, "Day" is assigned the type of "Days", then "Day" is a variable which can assume any one of seven different values. Moreover, "Day" can be assigned the value "mon", or "tue", etc., which makes the program easier to follow and understand. Internally, the Modula-2 system does not actually assign the value "mon" to the variable "Day", but it uses an integer representation for each of the names. This is important to understand because you must realize that you cannot print out "mon", "tue", etc., but can only use them for indexing control statements.

(* Chapter 10 - Program 1 *)
MODULE Entypes;

FROM InOut IMPORT WriteString, WriteLn;
FROM RealInOut IMPORT WriteReal;

TYPE Days = (mon,tue,wed,thu,fri,sat,sun);
     TimeOfDay = (morning,afternoon,evening,night);

VAR Day             : Days;
    Time            : TimeOfDay;
    RegularRate     : REAL;
    EveningPremium  : REAL;
    NightPremium    : REAL;
    WeekendPremium  : REAL;
    TotalPay        : REAL;

BEGIN    (* Main program *)
   WriteString('                         Pay rate table');
   WriteString('  DAY       Morning    Afternoon');
   WriteString('    Evening      Night');

   RegularRate := 12.00;      (* This is the normal pay rate *)
   EveningPremium := 1.10;    (* 10 percent extra for working late *)
   NightPremium := 1.33;      (* 33 percent extra for graveyard *)
   WeekendPremium := 1.25;    (* 25 percent extra for weekends *)

   FOR Day := mon TO sun DO

      CASE Day OF
        mon : WriteString('Monday   '); |
        tue : WriteString('Tuesday  '); |
        wed : WriteString('Wednesday'); |
        thu : WriteString('Thursday '); |
        fri : WriteString('Friday   '); |
        sat : WriteString('Saturday '); |
        sun : WriteString('Sunday   ');
      END;    (* of CASE statment *)

      FOR Time := morning TO night DO
         CASE Time OF
           morning   : TotalPay := RegularRate; |
           afternoon : TotalPay := RegularRate; |
           evening   : TotalPay := RegularRate * EveningPremium; |
           night     : TotalPay := RegularRate * NightPremium;
         END;  (* of CASE statement *)

         CASE Day OF
           sat : TotalPay := TotalPay * WeekendPremium; |
           sun : TotalPay := TotalPay * WeekendPremium;
         ELSE (* Do nothing *)
         END;  (* of CASE statement *)

      END;  (* of Time loop *)
   END;  (* of FOR loop *)

END Entypes.

Note that there is an upper limit of 16 enumerated types placed on you by most implementations of Modula-2. This is actually a very low limit and is most unfortunate that this limit exists.

The second line of the type definition defines "TimeOfDay" as another "type". The variable "Time" can only be assigned one of four values since it is defined as the type "TimeOfDay". It should be clear that even though it can be "morning", it cannot be assigned "morningtime" or any other variant spelling of morning, since it is simply another identifier which must have an exact spelling to be understood by the compiler.

Several REAL variables are defined to allow us to demonstrate the use of the scalar variables. After writing a header for our output, the REAL variables are initialized to some values that are probably not real life values, but will serve to illustrate use of the scalar variable.


The remainder of the program is one large loop being controlled by the variable "Day" as it goes through all of its values, one at a time. Note that the loop could have gone from "tue" to "sat" or whatever portion of the range desired. It does not have to go through all of the values of "Day". Using "Day" as the CASE variable, the name of one of the days of the week is written out each time we go through the loop. Another loop controlled by "Time" is executed four times, once for each value of "Time". The two CASE statements within the inner loop are used to calculate the total pay rate for each time period and each day. The data is formatted carefully to make a nice looking table of pay rates as a function of "Time" and "Day".

Take careful notice of the fact that the scalar variables never entered into the calculations, and they were not printed out. They were only used to control the flow of the logic. It was much neater than trying to remember that "mon" is represented by a 0, "tue" is represented by a 1, etc. In fact, those numbers are used for the internal representation of the scalars, but we can relax and let the Modula-2 system worry about the internal representation of our scalars.

Compile and run this program and observe the form of the output data. The only format available with some compilers are the "E" notation which does not make for a very well formatted or easily read output. Don't let this worry you, when we get to Part III of this tutorial we will see how we can write our own output routines to display, or print, floating point numbers in any format we can think up.

One other thing should be pointed out in this module. If you observe the CASE statements you will notice that the one that starts in line 33 does not have an ELSE clause. It is really not needed because every possible value that the variable "Day" can have is covered in the various branches. In the CASE statement starting in line 51, there is an ELSE clause because only two of the possible 7 values are acted on in the CASE body itself. Without the ELSE, the program would not know what to do with a value of "mon" through "fri", so the ELSE is required here, but not in the earlier one.


Examine the program SUBRANGE.MOD for an example of subranges. It may be expedient to define some variables that only cover a part of the full range as defined in a scalar type. Notice that "Days" is declared a scalar type as in the last program, and "Work" is declared a type with an even more restricted range. In the VAR declaration, "Day" is once again defined as the days of the week and can be assigned any of the days by the program. The variable "Workday", however, is assigned the type "Work", and can only be assigned the days "mon" through "fri". If an attempt is made to assign "Workday" the value "sat", a runtime error will be generated. A carefully written program will never attempt that, and it would be an indication that something is wrong with either the program or the data. This is one of the advantages of Modula-2 over older languages.

(* Chapter 10 - Program 2 *)
MODULE Subrange;

TYPE Days = (mon,tue,wed,thu,fri,sat,sun);
     Work = [mon..fri];
     Rest = [sat..sun];

VAR  Day      : Days;  (* This is any day of the week *)
     Workday  : Work;  (* These are the working days  *)
     Weekend  : Rest;  (* The two weekend days only   *)
     Index    : [1..12];
     Alphabet : ['a'..'z'];
     Start    : ['a'..'e'];

BEGIN    (* Main program *)
(*  The following statements are commented out because they
    contain various errors that will halt compilation.

   Workday := sat;   sat is not part of Workday's subrange.
   Rest := fri;      fri is not part of Rest's subrange.
   Index := 13;      Index is only allowed to go up to 12,
   Index := -1;        and down to 1.
   Alphabet := 'A';  Alphabet, as defined, includes only the
                       lowercase alphabet.
   Start := 'h';     h is not in the first five letters.

   End of the commented out section of program.

   Workday := tue;
   Weekend := sat;
   Day := Workday;
   Day := Weekend;
   Index := 3 + 2 * 2;
   Start := 'd';
   Alphabet := Start;
                            (* Since Alphabet is 'd'     *)
   INC(Alphabet);           (*   and now 'e'             *)
   Start := Alphabet;       (* Start will be 'e'         *)
   DEC(Start,2);            (* Start will be 'c'         *)
   Day := wed;
   INC(Day);                (* Day will now be 'thu'     *)
   INC(Day);                (* Day will now be 'fri'     *)
   Index := ORD(Day);       (* Index will be 4 (fri = 4) *)

END Subrange.

Further examination will reveal that "Index" is declared as being capable of storing only the range of INTEGERS from 1 to 12. During execution of the program, if an attempt is made to assign "Index" any value outside of that range, a runtime error will be generated. Suppose the variable "Index" was intended to refer to your employees, and you have only 12. If an attempt was made to refer to employee number 27, or employee number -8, there is clearly an error somewhere in the data and you would want to stop running the payroll to fix the problem. Modula-2 would have saved you a lot of grief.


In order to have a program that would compile without errors, and yet show some errors, the first part of the program is not really a part of the program since it is within a comment area. This is a trick to remember when you are debugging a program, a troublesome part can be commented out until you are ready to include it with the rest. The errors are self explanatory.

Going beyond the area commented out, there are seven assignment statements as examples of subrange variable use. Notice that the variable "Day" can always be assigned the value of either "Workday" or "Weekend", but the reverse is not true because "Day" can assume values that would be illegal for the other variables.


The last section of the example program demonstrates the use of three very important functions when using scalars. The first is the "INC" function which returns the value of the scalar following that scalar used as the argument. If the argument is the last value in the list, a runtime error is generated. The next function is the "DEC" that returns the value of the prior scalar to that used in the argument. All scalars have an internal representation starting at 0 and increasing by one until the end is reached. The third function is the "ORD" which simply returns the numerical value of the scalar variable.

In our example program, ORD(Day) is 5 if "Day" has been assigned "sat", but ORD(Weekend) is 0 if "Weekend" has been assigned "sat". As you gain experience in programming with scalars and subranges, you will realize the value of these three functions.

A few more thoughts about subranges are in order before we go on to another topic. A subrange is always defined by two predefined constants, and is always defined in an ascending order. A variable defined as a subrange type is actually a variable defined with a restricted range, and should be used as often as possible in order to prevent garbage data. There are actually very few variables ever used that cannot be restricted by some amount. The limits may give a hint at what the program is doing and can help in understanding the program operation. Subrange types can only be constructed using the simple data types.


Now for a new topic, sets. Examining the example program SETS.MOD will reveal use of some sets. A scalar type is defined first, in this case the scalar type named "Goodies". A set is then defined with the reserved words SET OF followed by a predefined scalar type. Most microcomputers have an upper limit of 16 elements that can be used in a set.

(* Chapter 10 - Program 3 *)

FROM InOut IMPORT WriteString, WriteLn;

TYPE Goodies = (IceCream,WhippedCream,Banana,Nuts,Cherry,

     Treat = SET OF Goodies;

VAR  Sundae       : Treat;
     BananaSplit  : Treat;
     Soda         : Treat;
     IceCreamCone : Treat;
     NuttyBuddy   : Treat;
     Mixed        : Treat;
     Index        : Treat;

        (* Define all ingredients used in each treat *)
IceCreamCone := Treat{IceCream,Cone};
Soda := Treat{Straw,SodaWater,IceCream,Cherry};
BananaSplit := Treat{IceCream..Caramel};
BananaSplit := BananaSplit + Treat{Spoon};
NuttyBuddy := Treat{Cone,IceCream,ChocSyrup,Nuts};
Sundae := Treat{IceCream,WhippedCream,Nuts,Cherry,ChocSyrup,

                (* Combine for a list of all ingredients used *)
Mixed := IceCreamCone + Soda + BananaSplit + NuttyBuddy +

                (* Now find what ingredients are not used *)

Mixed := Treat{IceCream..Stick} - Mixed;

   IF IceCream     IN Mixed THEN
                  WriteString('Ice cream not used');
                  WriteLn; END;
   IF WhippedCream IN Mixed THEN
                  WriteString('Whipped Cream not used');
                  WriteLn; END;
   IF Banana       IN Mixed THEN
                  WriteString('Bananas not used');
                  WriteLn; END;
   IF Nuts         IN Mixed THEN
                  WriteString('Nuts not used');
                  WriteLn; END;
   IF Cherry       IN Mixed THEN
                  WriteString('Cherries not used');
                  WriteLn; END;
   IF ChocSyrup    IN Mixed THEN
                  WriteString('Chocolate Syrup not used');
                  WriteLn; END;
   IF StrawBerries IN Mixed THEN
                  WriteString('Strawberries not used');
                  WriteLn; END;
   IF Caramel      IN Mixed THEN
                  WriteString('Caramel not used');
                  WriteLn; END;
   IF SodaWater    IN Mixed THEN
                  WriteString('SodaWater not used');
                  WriteLn; END;
   IF Salt         IN Mixed THEN
                  WriteString('Salt not used');
                  WriteLn; END;
   IF Pepper       IN Mixed THEN
                  WriteString('Pepper not used');
                  WriteLn; END;
   IF Cone         IN Mixed THEN
                  WriteString('Cone not used');
                  WriteLn; END;
   IF Straw        IN Mixed THEN
                  WriteString('Straw not used');
                  WriteLn; END;
   IF Spoon        IN Mixed THEN
                  WriteString('Spoon not used');
                  WriteLn; END;
   IF Stick        IN Mixed THEN
                  WriteString('Stick not used');
                  WriteLn; END;
END Sets.

Several variables are defined as sets of "Treat", after which they can individually be assigned portions of the entire set. Consider the variable "IceCreamCone" which has been defined as a set of type "Treat". This variable is composed of as many elements of "Goodies" as we care to assign to it. In the program, we define it as being composed of "IceCream", and "Cone". The set "IceCreamCone" is therefore composed of two elements, and it has no numerical or alphabetic value as most other variables have. Continuing in the program, you will see 4 more delicious deserts defined as sets of their components. Notice that the banana split is first defined as a range of terms, then another term is added to the group. All five are combined in the set named "Mixed", then "Mixed" is subtracted from the entire set of values to form the set of ingredients that are not used in any of the deserts. Each ingredient is then checked to see if it is IN the set of unused ingredients, and printed out if it is. Running the program will reveal a list of the unused elements.

In this example, better programming practice would have dictated defining a new variable, possibly called "Remaining" for the ingredients that were unused. It was desirable to illustrate that "Mixed" could be assigned a value based on subtracting itself from the entire set, so the poor variable name was used.

This example resulted in some nonsense results but hopefully it led your thinking toward the fact that sets can be used for inventory control, possibly a parts allocation scheme, or some other useful system.

CHAPTER 11 - Records


In order to do a profitable study of this material, you will need a good understanding of all of the material in Part I. The material concerning the scalar type from chapter 11 is also needed.

We come to the grandaddy of all data structures in Modula-2, the RECORD. A record is composed of a number of variables any of which can be of any predefined data type, including other records. Rather than spend time trying to define a record in detail, lets go right to the first example program, SMALLREC.MOD. This is a program using nonsense data that will illustrate the use of a record.

(* Chapter 11 - Program 1 *)
MODULE SmallRec;

FROM InOut   IMPORT WriteString, WriteCard, WriteLn;

TYPE Description = RECORD
       Year   : CARDINAL;
       Model  : ARRAY[0..20] OF CHAR;
       Engine : ARRAY[0..8] OF CHAR

VAR  Cars  : ARRAY[1..10] OF Description;
     Index : CARDINAL;

BEGIN   (* Main Program *)
   FOR Index := 1 TO 10 DO
      Cars[Index].Year := 1930 + Index;
      Cars[Index].Model := " Duesenberg";
      Cars[Index].Engine := "V8";

   Cars[2].Model := " Stanley Steamer";
   Cars[2].Engine := "Coal";
   Cars[7].Engine := "V12";
   Cars[9].Model := " Ford";
   Cars[9].Engine := "rusted";
   Cars[9].Year := 1981;

   FOR Index := 1 TO 10 DO
      WriteString(" has a ");
      WriteString(' engine.');
END SmallRec.


There is only one entry in the TYPE declaration part of the program, namely the record identified by "Description". The record is composed of three fields, the "Year", "Model", and "Engine" variables. Notice that the three fields are each of a different type, indicating that the record can be of mixed types. You have a complete example of the way a record is defined before you. It is composed of the identifier "Description", the reserved word RECORD, the list of elements, and followed by END;. Notice that this only defines a TYPE, it does not define any variables. That is done in the VAR declaration where the variable "Cars" is defined to have 10 complete records of the type "Description". The variable "Cars[1]" has three components, "Year", "Model", and "Engine", and any or all of these components can be used to store data pertaining to "Cars[1]".

In order to assign values to the various fields, the variable name is followed by the sub-field with a separating period. Keep in mind that "Cars[1]" is a complete record containing three variables, and to assign or use one of the variables, you must designate which sub-field you are interested in. See the program where the three fields are assigned meaningless data for illustration. The "Year" field is assigned an integer number varying with the subscript, all "Model" fields are assigned the name "Duesenburg", and all "Engine" variables are assigned the value "V8". In order to further illustrate that there are actually 30 variables in use here, a few are changed at random in the next few statements, being very careful to maintain the required types as defined in the TYPE declaration part of the program. Finally, all ten composite variables, consisting of 30 actual variables in a logical grouping are printed out using the same "var.subfield" notation described above.

If the preceding description of a record is not clear in your mind, review it very carefully. It's a very important concept in Modula-2, and you won't have a hope of a chance of understanding the next example until this one is clear.


Examine the example file BIGREC.MOD for a very interesting record. First we have a constant defined. Ignore it for the moment, we will come back to it later. Within the TYPE declaration we have three records defined, and upon close examination, you will notice that the first two records are included as part of the definition of the third record. The record identified as "Person", actually contains 8 variable definitions, three within the "FullName" record, two of its own, and three within the "Date" record. This is a TYPE declaration and does not actually define any variables, that is done in the VAR part of the program.

(* Chapter 11 - Program 2 *)

FROM InOut   IMPORT WriteString, Write, WriteLn;

CONST  NumberOfFriends = 50;

TYPE   FullName = RECORD
         FirstName : ARRAY[0..12] OF CHAR;
         Initial   : CHAR;
         LastName  : ARRAY[0..15] OF CHAR;

       Date = RECORD
         Day, Month, Year : CARDINAL;

       Person = RECORD
         Name     : FullName;
         City     : ARRAY[0..15] OF CHAR;
         State    : ARRAY[0..3] OF CHAR;
         BirthDay : Date;

VAR   Friend             : ARRAY[1..NumberOfFriends] OF Person;
      Self,Mother,Father : Person;
      Index              : CARDINAL;

BEGIN  (* Main Program *)
   Self.Name.FirstName := "Charley";
   Self.Name.Initial := 'Z';
   Self.Name.LastName := "Brown";

   WITH Self DO
      City := "Anywhere";
      State := "CA";
      BirthDay.Day := 17;
      WITH BirthDay DO
         Month := 7;
         Year := 1938;
   END;   (* All data for Self now defined *)

   Mother := Self;
   Father := Mother;

   FOR Index := 1 TO NumberOfFriends DO
      Friend[Index] := Mother;

   WriteString(' ');
   WriteString(' ');
END BigRec.

The VAR part of the program defines some variables beginning with the array of "Friend" containing 50 (because of the constant definition in the CONST part) records of "Person". Since "Person" defines 8 fields, we have now defined 8 times 50 = 400 separate and distinct variables. Each of the 400 separate variables has its own type associated with it, and the compiler will generate an error if you try to assign any of those variables the wrong type of data. Since "Person" is a TYPE definition, it can be used to define more than one variable, and in fact it is used again to define three more records, "Self", "Mother", and "Father". These three records are each composed of 8 variables, so we have 24 more variables which we can manipulate within the program. Finally we have the variable "Index" defined as a simple CARDINAL type variable. Notice that if we desired, we could also define a variable of type "FullName" composed of 3 simple variables.


In the program we begin by assigning data to all of the fields of "Self". Examining the first three statements of the main program, we see the construction we learned in the last example program being used, namely the period between descriptor fields. The main record is named "Self", and we are interested in the first part of it namely the "Name" part of the person record. Since the "Name" part of the person record is itself composed of three parts, we must designate which part of it we are interested in. The complete description "Self.Name.FirstName" is the complete description of the first name of "Self" and is the first assignment statement which is assigned the name of "Charley". The next two fields are handled in the same way and are self explanatory.


Continuing on to the fourth field, the "City", there are only two levels required because "City" is not another record definition. The fourth field is therefore completely defined by "Self.City". Notice the "WITH Self DO" statement. This is a shorthand notation used with record definitions to simplify coding. From the BEGIN at the next statement to the matching END; about 10 statements later, any variables within the "Self" record are used as though they had a "Self." in front of them. It greatly simplifies coding to be able to omit the leading identifier within the WITH section of code. You will see that "City", and "State", are easily assigned values without further reference to the "Self" variable. When we get to the "Day" part of the birthday, we are back to three levels and the complete definition is "Self.Birthday.Day" but once again, the "Self." part is taken care of automatically because we are still within the "WITH Self DO" area.

To illustrate the WITH statement further, another is introduced, "WITH Birthday DO", and an area is defined by the BEGIN END pair. Within this area both leading identifiers are handled automatically to simplify coding, and "Month" is equivalent to writing "Self.Birthday.Month" if both WITH statements were removed. You may be wondering how many levels of nesting are allowed in record definitions. There doesn't appear to be a limit according to the Modula-2 definition, but we do get a hint at how far it is possible to go. In most implementations of Modula-2, you are allowed to have WITH statements nested to nine levels, and it would be worthless to nest WITH statements deeper than the level of records. Any program requiring more levels than nine is probably far beyond the scope of your programming ability, and mine, for a long time.

After assigning a value to the year, the entire record of "Self" is defined, all eight variables.


The next statement, "Mother := Self;" is very interesting. Since both of these are records, both are the same type of record, and both therefore contain 8 variables, Modula-2 is smart enough to recognize that, and assign all eight values contained in "Self" to the corresponding variables of "Mother". So after one statement, "Mother" is completely defined. The next statement assigns the same values to the eight respective fields of "Father", and the next two lines assign all 50 "Friend" variables the same data. We have therefore generated 400 + 24 = 424 separate pieces of data so far in this program. We could print it all out, but since it is nonsense data, it would only waste time and paper. The next three lines write out three sample pieces of the data for your inspection.


It should be obvious to you that what this program does, even though the data is nonsense, appears to be the beginning of a database management program, which indeed it is. It is a crude beginning, and has a long way to go to be useful, but you should see a seed for a useful program.

Now to go back to the CONST as promised. The number of friends was defined as 50 and used for the size of the array and in the assignment loop near the end of the program. You can now edit this number and see how big this database can become on your computer. Your compiler should be capable of storing about 1000 records even within the smallest model available on any compiler. If your compiler uses a larger memory model, you will be able to store significantly more records. See how big you can make the number of friends before you get the memory overflow message. Keep the number in mind because when we get to the chapter on Pointers and Dynamic Allocation, you should see a marked increase in allowable size, especially if you have a large amount of RAM installed in your computer. If your compiler uses a large memory model, you won't see an increase in size but it will be an interesting exercise anyway.


If any part of this chapter is still unclear, it would be good for you to go back and review it at this time. The next example will really tax your mind to completely understand it, especially if the prior material is not clear.

Examine the program VARREC.MOD for an example of a program with a variant record definition. In this example, we first define a scalar type, namely "KindOfVehicle" for use within the record. Then we have a record defining "Vehicle", intended to define several different types of vehicles, each with different kinds of data. It would be possible to define all variables for all types of vehicles, but it would be a waste of storage space to define the number of tires for a boat, or the number of propeller blades used on a car or truck. The variant record lets us define the data precisely for each vehicle without wasting data storage space.

(* Chapter 11 - Program 3 *)

FROM InOut   IMPORT WriteString, WriteInt, WriteLn;

TYPE   KindOfVehicle = (Car,Truck,Bicycle,Boat);

       Vehicle = RECORD
         OwnerName   : ARRAY[0..25] OF CHAR;
         GrossWeight : CARDINAL;
         Value       : REAL;
         CASE WhatKind : KindOfVehicle OF
           Car     : Wheels  : CARDINAL;
                     Engine  : ARRAY[0..12] OF CHAR |
           Truck   : Motor   : ARRAY[0..8] OF CHAR;
                     Tires   : CARDINAL;
                     PayLoad : CARDINAL            |
           Bicycle : Tyres   : INTEGER             |
           Boat    : PropBlades : INTEGER;
                     Sail    : BOOLEAN;
                     Power   : ARRAY[0..8] OF CHAR;
         END; (* of CASE *)
       END;   (* of record *)

VAR   Sunfish, Ford, Schwinn, Mac : Vehicle;

   Ford.OwnerName := "Walter";         (* Fields defined in order *)
   Ford.GrossWeight := 5750;
   Ford.Value := 2595.00;
   Ford.WhatKind := Truck;
   Ford.Motor := "V8";
   Ford.Tires := 18;
   Ford.PayLoad := 12000;

   WITH Sunfish DO
      WhatKind := Boat;      (* Fields defined in random order *)
      Sail := TRUE;
      PropBlades := 3;
      Power := "Wind";
      GrossWeight := 375;
      Value := 1300.00;
      OwnerName := "Herman and George";

   Ford.Engine := "Flathead";         (* Tag-field not defined yet *)
   Ford.WhatKind := Car;              (* but it must be before it  *)
                                      (* can be referred to        *)
   Ford.Wheels := 4;        (* Notice that the non-variant part is *)
                            (* not redefined here.                 *)

   Mac := Sunfish;    (* Entire record copied, including tag-field *)

   IF Ford.WhatKind = Car THEN                (* This should print *)
      WriteString(" owns the car with the ");
      WriteString(' engine.');

   IF Sunfish.WhatKind = Bicycle THEN     (* This should not print *)
      WriteString("The sunfish is a bicycle");

   IF Mac.WhatKind = Boat THEN                (* This should print *)
      WriteString("The Mac is now a boat with");
      WriteString(" propeller blades.");
END VarRec.


In the record definition we have the usual RECORD header followed by three variables defined in the same manner as the records in the last two example programs. Then we come to the CASE statement. Following this statement, the record is different for each of the four types defined in the associated scalar definition. The variable "WhatKind" is called the tag-field and must be defined as a scalar type prior to the record definition. The tag-field is what selects the variant used, when the program uses one of the variables with this record type. The tag-field is followed by a colon and its type definition, then the reserved word OF. A list of the variants is then given, with each of the variants having the variables for its particular case defined. The list of variables for one variant is called the field list.

A few rules are in order at this point. The variants do not have to have the same number of variables in each field list, and in fact, one or more of the variants may have no variables at all in its variant part. If a variant has no variables, it must still be defined with a blank followed by a semi-colon. All variables in the entire variant part must have unique names. The three variables, "Wheels", "Tires", and "Tyres", all mean the same thing to the user, but they must be different for the compiler. You may use the same identifiers again in other records and for simple variables anywhere else in the program. The Modula-2 compiler can tell which variable you mean by its context. Using the same variable name should be discouraged as bad programming practice because it may confuse you or another person trying to understand your program at a later date.


We properly define four variables with the record type "Vehicle" and go on to examine the program itself.

We begin by defining one of our variables of type "Vehicle", namely the variable named "Ford". The seven lines assigning values to "Ford" are similar to the prior examples with the exception of the fourth line. In the fourth line the tag-field which selects the particular variant used is set equal to the value "Truck", which is a scalar definition, not a variable. This means that the variables named "Motor", "Tires", and "Payload" are available for use with the record "Ford", but the variables named "Wheels", "Engine", "Tyres", etc. are not available in the record named "Ford".

Next, lets define the record "Sunfish" as a boat, and define all of its variables. All of sunfish's variables are defined but in a rather random order to illustrate that they need not be defined in a particular order. Recall the use of WITH from the last example program.

To go even further in randomly assigning the variables to a record, we redefine "Ford" as having an "Engine" which it can only have if it is a car. This is one of the fine points of the record. If you assign any of the variant variables, the record is changed to that variant, but it is the programmers responsibility to assign the correct tag- field to the record, not the Modula-2 compiler's. Good programming practice would be to assign the tag-field before assigning any of the variant variables. The remainder of the "Ford" variables are assigned to complete that record, the non-variant part remaining from the last assignment.

The variable "Mac" is now set equal to the variable "Sunfish". All variables within the record are copied to "Mac" including the tag-field, making "Mac" a boat.


We have assigned "Ford" to be a car, and two boats exist, namely "Sunfish" and "Mac". Since "Schwinn" was never defined, it has no data in it, and is at this point useless. The "Ford" tag-field has been defined as a car, so it should be true in the IF statement, and the first message should print. The "Sunfish" is not a bicycle, so it will not print. The "Mac" has been defined as a boat in the single assignment statement, so it will print a message with an indication that all of the data in the record was transferred to its variables.

Even though we can make assignment statements with records, they cannot be used in any mathematical operations such as addition, or multiplication. They are simply used for data storage. It is true however, that the individual elements in a record can be used in any mathematical statements legal for their respective types.

One other point should be mentioned. The tag-field can be completely eliminated resulting in a "free union" variant record. This is possible because Modula-2, as you may remember from above, will automatically assign the variant required when you assign data to one of the variables within a variant. This is the reason that all variables within any of the variants must have unique names. The free union record should be avoided in your early programming efforts because you cannot test a record to see what variant it has been assigned to.


A record with a free union variant is commonly used in Pascal to do type transfers, but this should be discouraged in Modula-2 since it has a complete set of carefully defined type transfer functions for that purpose. In addition, the method of data storage is not specified as a part of the language and a free union would not operate the same way with different compilers if used for the purpose of type transfer.


1. Write a simple program with a record to store the names of five of your friends and display the names.

CHAPTER 12 - Pointers and Dynamic Allocation


In order to understand this chapter, you should have a good grasp of the entirety of Part I and a clear understanding of chapter 11.

For certain types of programs, pointers and dynamic allocation can be a tremendous advantage, but most programs do not need such a high degree of data structure. For that reason, it would probably be to your advantage to lightly skim over these topics and come back to them later when you have a substantial base of Modula-2 programming experience. It would be good to at least skim over this material rather than completely neglecting it, so you will have an idea of how pointers and dynamic allocation work and that they are available for your use when needed.

A complete understanding of this material will require deep concentration as it is very complex and not at all intuitive. Nevertheless, if you pay close attention, you will have a good grasp of pointers and dynamic allocation in a short time.


If you examine POINTERS.MOD, you will see a very trivial example of pointers and how they are used. In the VAR declaration, you will see that the two variables have the two reserved words POINTER TO in front of their respective types. These are not actually variables, instead, they point to dynamically allocated variables that have not been defined yet, and they are called pointers. We will see, when we get to chapter 14, that a pointer can be used to point to any variable, even a statically defined one, but that will have to wait awhile.

(* Chapter 12 - Program 1 *)
MODULE Pointers;

FROM InOut   IMPORT WriteString, WriteInt, WriteLn;

TYPE Name = ARRAY[0..20] OF CHAR;

VAR  MyName : POINTER TO Name;    (* MyName points to a string *)
     MyAge  : POINTER TO INTEGER; (* MyAge points to an INTEGER *)



   MyAge^ := 27;
   MyName^ := "John Q. Doe";

   WriteString("My name is ");
   WriteString(" and I am ");
   WriteString(" years old.");


END Pointers.

The pointer "MyName" is a pointer to a 20 character string and is therefore not a variable into which a value can be stored. This is a very special TYPE, and it cannot be assigned a character string, only a pointer value or address. The pointer actually points to an address somewhere within the computer memory, and can access the data stored at that address.

Your computer has some amount of memory installed in it. If it is an IBM-PC or compatible, it can have up to 640K of RAM which is addressable by various programs. The operating system requires about 60K of the total, and your program can use up to 64K assuming that your compiler uses a small memory model. Adding those two numbers together results in about 124K. Any memory you have installed in excess of that is available for the stack and the heap. The stack is a standard DOS defined and controlled area that can grow and shrink as needed. Many books are available to define the stack if you are interested in more information on it.

The heap is a Modula-2 entity that utilizes otherwise unused memory to store data. It begins immediately following the program and grows as necessary upward toward the stack which is growing downward. As long as they never meet, there is no problem. If they meet, a run-time error is generated. The heap is therefore outside of the actual program space.

If you did not understand the last two paragraphs, don't worry. Simply remember that dynamically allocated variables are stored on the heap and do not count in the 64K limitation placed upon you by some compilers.

Back to our example program, POINTERS.MOD. When we actually begin executing the program, we still have not defined the variables we wish to use to store data in. The first executable statement in line 15 generates a variable for us with no name and stores it on the heap. Since it has no name, we cannot do anything with it, except for the fact that we do have a pointer "MyAge" that is pointing to it. By using the pointer, we can store any INTEGER in it, because that is its type, and later go back and retrieve it.


The variable we have just described is a dynamically allocated variable because it was not defined in a VAR declaration, but with an ALLOCATE procedure. The ALLOCATE procedure creates a variable of the type defined by the pointer, puts it on the heap, and finally assigns the address of the variable to the pointer itself. Thus "MyAge" contains the address of the variable generated. The variable itself is referenced by using the pointer to it followed by a ^, and is read, "the variable to which the pointer points".

The ALLOCATE procedure requires 2 arguments, the first of which is a pointer which will be used to point to the desired new block of dynamically allocated menory, and the second which gives the size of the block in bytes. The supplied function TSIZE will return the size of the block of data required by the TYPE supplied to it as an argument. Be sure to use the TYPE of the data and not the TYPE of the pointer to the data for the argument. Another procedure is available named SIZE which returns the size of any variable in bytes.

The next statement assigns a place on the heap to an ARRAY type variable and puts its address in "MyName". Following the ALLOCATE statements we have two assignment statements in which the two variables pointed at are assigned values compatible with their respective types, and they are both written out to the video display. Notice that both of these operations use the ^ which is the dereference operator. By adding the dereference operator to the pointer name, you can use the entire name just like any other variable name.

The last two statements are illustrations of the way the dynamically allocated variables are removed from use. When they are no longer needed, they are disposed of with the DEALLOCATE procedure, and the space on the heap is freed up for use by other dynamically allocated variables.

In such a simple program, pointers cannot be appreciated, but it is necessary for a simple illustration. In a large, very active program, it is possible to define many variables, dispose of some of them, define more, and dispose of more, etc. Each time some variables are deallocated, their space is then made available for additional variables defined with the ALLOCATE procedure.

The heap can be made up of any assortment of variables, they do not have to all be the same. One thing must be remembered. Anytime a variable is defined, it will have a pointer pointing to it. The pointer is the only means by which the variable can be accessed. If the pointer to the variable is lost or changed, the data itself is lost for all practical purposes.


The NEW and DISPOSE procedures are a carryover from Pascal and are available on some Modula-2 compilers. When they are available, they are simply translated internally into calls to ALLOCATE and DEALLOCATE which must be imported in order to use NEW and DISPOSE. Since they are being removed from the language definition, their use should be discouraged in favor of the more universal ALLOCATE and DEALLOCATE procedures.


The next example program, DYNREC.MOD, is a repeat of one we studied in an earlier chapter. For your own edification, review the example program BIGREC.MOD before going ahead in this chapter.

(* Chapter 12 - Program 2 *)

FROM InOut   IMPORT WriteString, Write, WriteLn;

CONST  NumberOfFriends = 50;

TYPE   FullName = RECORD
         FirstName : ARRAY[0..12] OF CHAR;
         Initial   : CHAR;
         LastName  : ARRAY[0..15] OF CHAR;

       Date = RECORD
         Day   : CARDINAL;
         Month : CARDINAL;
         Year  : CARDINAL;

       PersonID = POINTER TO Person;
       Person = RECORD
         Name      : FullName;
         City      : ARRAY[0..15] OF CHAR;
         State     : ARRAY[0..3] OF CHAR;
         BirthDay  : Date;

VAR   Friend  : ARRAY[1..NumberOfFriends] OF PersonID;
      Self, Mother, Father : PersonID;
      Temp    : Person;
      Index   : CARDINAL;

BEGIN  (* Main program *)
   ALLOCATE(Self,TSIZE(Person));    (* Create a dynamically
                                                allocated variable *)
   Self^.Name.FirstName := "Charley ";
   Self^.Name.Initial := 'Z';
   Self^.Name.LastName := " Brown";
   WITH Self^ DO
      City := "Anywhere";
      State := "CA";
      BirthDay.Day := 17;
      WITH BirthDay DO
         Month := 7;
         Year := 1938;
   END;     (* All data for Self is now defined *)

   Mother := Self;

   Father^ := Mother^;

   FOR Index := 1 TO NumberOfFriends DO
      Friend[Index]^ := Mother^;

   Temp := Friend[27]^;

(* DEALLOCATE(Mother,TSIZE(Person)); Since Mother is lost, it cannot
                                                    be disposed of *)
   FOR Index := 1 TO NumberOfFriends DO

END DynRec.

Assuming that you are back in DYNREC.MOD, you will notice that this program looks very similar to the earlier one, and in fact they do exactly the same thing. The only difference in the TYPE declaration is the addition of a pointer "PersonID", and in the VAR declaration, the first four variables are defined as pointers here, and were defined as record variables in the last program.


Notice in the TYPE declaration that we used the identifier "Person" before we defined it, which is illegal in Modula-2. Foreseeing the need to define a pointer prior to the record, the designer of Modula-2 allows us to break the rule in this one place. The pointer could have been defined after the record in this case, but it was more convenient to put it before, and in the next example program, it will be required to put it before the record. We will get there soon.

Examining the VAR declaration, we see that "Friend" is really 50 pointers, so we have now defined 53 different pointers to records, but no variables other than "Temp" and "Index". We dynamically allocate a record with "Self" pointing to it, and use the pointer to fill the new record. Compare the statements that fill the record with the c