Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!husc6!seismo!rochester!pt.cs.cmu.edu!f.gp.cs.cmu.edu!rpd
From: rpd@f.gp.cs.cmu.edu (Richard Draves)
Newsgroups: net.lang.mod2
Subject: Re: Single Pass Modula-2 Compiler
Message-ID: <11@f.gp.cs.cmu.edu>
Date: Tue, 14-Oct-86 10:43:13 EDT
Article-I.D.: f.11
Posted: Tue Oct 14 10:43:13 1986
Date-Received: Fri, 17-Oct-86 08:07:02 EDT
References: <12243102365.25.KURKURE@Sushi.Stanford.EDU> <841@cuuxb.UUCP> <8@f.gp.cs.cmu.edu> <851@cuuxb.UUCP> <20@oresoft.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 20
Keywords: One-pass, Internal Modules

First, I want to clarify my definition of a one-pass compiler.  Ideally,
a one-pass compiler can compile program of unbounded size using a bounded
memory.  Problems with symbol table size may make this impossible, but
I think that captures most people's intuition.

This rules out reading the entire program into memory in the form of
a syntax tree and then generating code.  It also rules out saving
large amounts of information (can be as much as every reference to
a non-local variable/function/type in a statement) for later type-checking
and back-patching.

Mutually importing modules are an interesting idea.  This summer
I tried a considerable number of test programs, using both the
Powell compiler and the Hamburg compiler.  If I remember the results
correctly, neither accepted the obvious attempts, but the Powell
compiler would accept some examples when one module was local to the other.
The language definition is so vague that a compiler can do almost anything
it want for programs that are off the beaten path.

Rich