🚀 go-pugleaf

Two rejoinders to Mr. Heiser

1st.
IMPORT clauses are not declarations, they merely make identifiers
visible outside the scope surrounding their declaration.  Your quote from PIM2:
"Every identifier occuring in a program must be introduced by a declaration,
unless it is a standard identifier" does not require a declaration in each
MODULE, but rather one declaration in each program.  Also, check the syntax
diagrams (or EBNF productions) for "declaration" in the back.  Declarations
occur only in "blocks" which occur in "ProcedureDeclaration",
"ModuleDeclaration", and "ProgramModule", in the latter two _after_ the
imports and exports.

2d. about timestamping --
A reminder of a subtle point:  standard operation of the Powell compiler
is not the default, but rather requires invocation with the "-s -M" options.
It appears that you never explicitly requested the inter-module checking
that you desired.  (I don't propose to justify that argument passing
design, just remember it.)

My supposition about the contents of .o files was mostly wrong.  It appears
from experiment (without access to the sources) that the intermodule checker
does not operate by means of a time-stamping scheme, but attempts to meet
the same requirements by comparing for consistency the binary-form copies
of every DEFINITION MODULE, as found in the .o file of each MODULE that
IMPORTs it.  So, one way to view the approach is to say that the .def file
gets compiled every time a client IMPLEMENTATION MODULE is compiled.

As far as I can see, Wirth did not specify how the compiler was to organize
its object code, as long as it:
A. allows separate compilation of "compilation units"
B. guarantees independence of client MODULEs from the implementation
     of MODULEs imported
C. provides "full type compatibility checking between objects", even across
     MODULE boundaries.
Timestamping is one implementation method for ensuring consistent
type-checking, though not the only one.  Powell's compiler ensures consistency
even for cases where a time-stamping implementation would require unnecessary
recompilation, say, because of comments having been added, for example.

Mr. Heiser's code example just shows what happens when one alters a DEFINITION
MODULE and neglects to recompile the .def file.  Exactly the same thing
happens with the Cambridge compiler.  The solution to the problem of
forgetting to recompile .def files is to use make.

Come to think of it, users of make with correct makefiles would find most
of the difficulties discussed here to be of academic interest only.


Vincent Broman,  code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA
Phone: +1 619 225 2365    Internet: broman@nosc.mil   Uucp: sdcsvax!nosc!broman