OVERALL PROGRAM CONSTRUCTION
HOW TO PUT IT ALL TOGETHER
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.
Examine the program named OVERPROG.MOD for ================
our first look at the overall structure of OVERPROG.MOD
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.
The program on display contains several levels of nested
procedures as an illustration for you. The main program has
lines 3 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 can actually be
called by the main program, Proc1, and Proc2, because they are
the only procedures at the same level as the main program.
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.
WHO CAN CALL WHO?
It is important for you to clearly understand which procedure
can call which other procedures. A procedure can call any
Chapter 7 - Overall Program Construction
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 and at the
same level as 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.
There is one additional rule about procedure calling. A
procedure can call any procedure that is a peer of any of its
ancestors. This means that the executable part of Proc5 can
call Proc3 or Proc1 because they are peers of Proc4 and Proc2
respectively, which are both ancestors of Proc5.
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 side
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 helps in designing a clear, understandable program. Note
that function procedures can also be nested in this manner if
desired. Compile and run this program and study the output
from it until you understand it completely.
WHERE DO CONSTANTS, TYPES, AND VARIABLES GO?
Examine MOREPROG.MOD, for examples of ================
where you can put the other definitions in MOREPROG.MOD
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. Notice lines 45 through 48 where
the use of a global type and other types defined in ancestor
procedures are illustrated. Study these lines until you
understand where the types are coming from. Some time spent
studying this program should aid you in understanding even
better the overall program construction problem.
Chapter 7 - Overall Program Construction
WHAT ABOUT ORDER OF DECLARATIONS?
Load the program LASTPROG.MOD for an ================
example of how the various fields can be LASTPROG.MOD
ordered in the declaration part of the ================
program. Notice that there are 2
procedures, two constants, two types, and two variables
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 in Modula-2, as long as
everything is defined before it is used.
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, if it exists, 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.