Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!midway!iitmax!gkt
From: gkt@iitmax.IIT.EDU (George Thiruvathukal)
Newsgroups: comp.lang.modula2
Subject: Re: Modula-2 "object" format for def'n module?
Summary: What to do with DEFINITION modules (or IMPORTS)
Keywords: Modula-2 definition
Message-ID: <4451@iitmax.IIT.EDU>
Date: 1 Nov 90 06:06:05 GMT
References: <josef.657189394@peun11>
Organization: Illinois Institute of Technology, Chicago
Lines: 67

In article <josef.657189394@peun11>, josef@nixdorf.de (Moellers) writes:
> Hi,
> I am currently busy to write my own Modula-2 compiler.
> Although progress is very slow, I would like to know if someone could
> give me any hints on the format of compiled "DEFINITION MODULE"s.

I have never written a compiler for Modula-2 but can perhaps shed some light
on how one might implement DEFINITION modules.  There are two approaches which
have been used by the various Modula-2 compiler implementors:

  1. When an IMPORT is encountered, parse the DEFINITION module for its symbols
     and incorporate the symbols into the symbol table for the current module
     (or unit) of compilation.

  2. When an IMPORT is encountered, look for a symbol file corresponding to the
     DEFINITION module and load the symbols into the symbol table for the
     current module (or unit) of compilation.

Each of these implementation strategies has its merits and shortcomings.  Let
us examine strategy #1.  A parse of the DEFINITION module is equivalent to the
notion of an include file in C.  If a number of modules in a given project 
import objects from a common module, the compiler has to parse the same text
over and over again (as occurs in C in a multiple "module" project).  For large
DEFINITION modules, the compile time for the entire project can be long.  The
advantage of the treatment of DEFINITION modules as include files is simplicity.
From the standpoint of the compiler, the state of the scanner and the parser 
must merely be pushed onto a stack (a simple context switch) and restarted with
the new file (the DEFINITION module).  It is trivial, which is why many 
compiler vendors implement it.  Frequently, the vendors of Modula-2 compilers
argue from the standpoint that processors are getting faster and memory much
cheaper, so why should we bother to follow another avenue?

Strategy #2 obviously remedies the potentially long compilation times for real
world projects.  The first time an import of a module occurs, a symbol file is
sought (with the same prefix as the module).  If it is not found, the DEFINITION
module is parsed for its declarations and translated into a symbol file.  The
symbol file can be virtually any format, but it would make sense for the format
to be an "image" form which could be rapidly read into the symbol table for the
current unit of compilation.  In the event the symbol file is found, the symbol
file is either up-to-date or out-of-date.  If the symbol file is out-of-date, 
the symbol file must be produced according to the previous discussion, as if 
the symbol file was not present; otherwise, the symbol file is read into the
symbol table for the current unit of compilation.  Obviously, the idea of 
symbol files requires more work (and creates more clutter) but can pay big 
dividends for large projects (which is real world stuff) where files included
can be common to many modules and can be very large.  It is not so trivial to
implement, and it certainly involves an implementation of strategy #1.  One
can circumvent the partial implementation of strategy #1 by leaving it to Joe
User to "compile" every DEFINITION module into a symbol file.  But why should
the user have to do "compiler" work?

Well, I hope I have adequately defined the working theory for the management
of DEFINITION modules in Modula-2 compilers with which I have worked.  If I
were doing a compiler for Modula-2, I would opt (as a maverick) for strategy
#2.  Although our computing resources are apparently infinite these days, I
am under the impression that one should always endeavor to design software
with these guidelines:
   1. it should work efficiently
   2. it should use the resources well and avoid waste!
   3. it should not be user-hostile (it should do the dirty work)
   4. it should be modular

Thank you for reading.  I am elated to notice some topics of substance (and
not Satan) emerging in our treasured newsgroup.

George Thiruvathukal
gkt@iitmax.iit.edu