aplusl@ethz.UUCP (Albert Meier) (07/23/88)
Expires:
Sender:
Reply-To: aplusl@bernina.UUCP (Albert Meier)
Followup-To:
Distribution: comp.lang.modula2
Organization: ETH Zuerich, Switzerland
Keywords: Compilers, Scope
Proposal of a possible solution to standardize one version of
Modula-2 that may be correctly compiled by Single and Multi Pass
Compilers
Introduction
As several previous papers show there are difficulties to
standardize one version of Modula-2 that may be correctly
compiled by Single Pass Compilers (SPC) and Multi Pass Compilers
(MPC).
To summarize the problems we try to take the viewpoint of looking
at each compiler that has to compile modules written in the
"other's dialect". We first look at the problem at compile time
then at run time and second try to define the needed steps to
make the program properly work. We also try to define the level
of difficulty to make the needed changes. At the end we try to
give a solution how compilers have to be built to resolve most of
the problems mentioned yet.
MPC compiling SPC Modula-2
Due to its multiple passes an MPC doesn't need objects to be
declared in a specific order, especially that objects have to be
declared before they are used. This leads to the problem that
there is no need for FORWARD declarations and such are also not
handled. The compiler gives an error, the module seems not to be
correct.
To make the module pass the compiler without an error we need to
delete all FORWARD declarations or to make them invisible for the
compiler. To make such changes is an easy task.
SPC compiling MPC Modula-2
Due to its single pass concept an SPC marks every occurrence of
an object that isn't declared before its use as an error.
(Exception: POINTER pointing to a type which is declared directly
following the declaration of the POINTER.)
Here we need to reorder the program text or, if this is not
possible or not wished, to declare objects as FORWARD. This is an
easy job if the module is well structured.
Special
It is our opinion that mutually imported objects from/by local
modules mentioned in previous papers is not a specific problem of
an SPC but of an MPC as well, because it may lead to side effects
and even to undefined states at run time. Because we think that
standards shouldn't support bad practices by standardizing them
we propose to suggest Modula-2 users not to mutually import
objects from any modules, local and external.
Problem at run time
There is one specific problem at run time running a program
written in the "other's dialect" that is also mentioned in
previous papers: If we have nested scopes and use an object in an
inner level before its declaration in the respective inner scope
where an object of the same type and name has been declared in an
outer scope before, the program would behave in a different way
depending with which compiler it was compiled. The program
compiled with an MPC would (correctly) use the object of the
respective scope, compiled with an SPC it would use the first
declared object that should be hidden by the object declared in
the inner scope. The SPC doesn't find an error, but the program
works differently.
Here again we need to reorder the program text or, if this is not
possible or not wished, to declare objects as FORWARD. But now
this may be a very difficult task because we have first to find
out where and which object causes the unexpected behavior.
How compilers could be built to resolve these problems
To be able to define one version of Modula-2 that may be compiled
by SPCs and MPCs we have to demand the following:
MPCs have to accept the FORWARD statement and have even to check
names and types of objects (and of parameters) against the main
declaration. There is hardly no reduction in compiling speed and
almost no additional complexity to build the compiler.
SPCs have to check for all scope levels whether an object is
declared after its use in the same or a lower level. Such
declarations have to be marked as an error. Tests show that there
is only little reduction in compiling speed, little additional
complexity to build the compiler and little need for additional
storage requirements.
SSS N N V V SNV SWISS STANDARDIZATION BODY
S NN N V V 149/UK2 Programming Languages
SSS N N N V V Chairman Albert Meier, CH-8906 Bonstetten
S N NN V V . E-mail aplusl@ifi.ethz.(ch/UUCP)
SSS N N V ...mcvax!cernvax!ethz!aplusl