🚀 go-pugleaf

In article <12243102365.25.KURKURE@Sushi.Stanford.EDU> KURKURE@SUSHI.STANFORD.EDU (Uday Kurkure) writes:
>    Having merged Logitech's Modula-2 compiler's pass1 and pass2 into
>    a single pass,  I think that if you have identifiers used in
>    statments before declaring them, it is not possible to have 
>    a one pass compiler because you can not do the type checking in a 
>    reasonable way.

	Actually, you can note the fact that whatever type the symbol has
    must be compatable with how it is being used, and check that against
    the actual declaration when you see it.  For example, if I see a
    function call:

    intvar := funct( 5.0, "test", 7 );

    I can note that funct must return a type that can be assigned to an int,
    and accept a floating point, char array, and integer argument;  then,
    when I see a declaration of funct, I can check against this usage, and
    determine whether the previous usage was correct.  While this may seem
    to be a lot of bookkeeping, it seems to me the gains in speed for a 
    one pass compiler are sufficient to warrant it.  I may also need to
    back-patch some appropriate type conversions (i.e. integer->real, etc.).

-- 
 Marc Mengel
 ...!ihnp4!cuuxb!mwm

In article <841@cuuxb.UUCP> mwm@cuuxb.UUCP (Marc W. Mengel) writes:
>	Actually, you can note the fact that whatever type the symbol has
>    must be compatable with how it is being used, and check that against
>    the actual declaration when you see it.  For example, if I see a
>    function call:
>
>    intvar := funct( 5.0, "test", 7 );
>
>    I can note that funct must return a type that can be assigned to an int,
>    and accept a floating point, char array, and integer argument;  then,
>    when I see a declaration of funct, I can check against this usage, and
>    determine whether the previous usage was correct.  While this may seem
>    to be a lot of bookkeeping, it seems to me the gains in speed for a 
>    one pass compiler are sufficient to warrant it.  I may also need to
>    back-patch some appropriate type conversions (i.e. integer->real, etc.).

And what if it turns out that funct is really a type, and that statement
should have been flagged as a syntax error?  I think that if you really
look carefully at what your proposal would do to calling sequences, and
the amount of backpatching that would be needed, you'll agree that it's
impractical at best.

Rich

In article <8@f.gp.cs.cmu.edu> rpd@f.gp.cs.cmu.edu (Richard Draves) writes:
>In article <841@cuuxb.UUCP> mwm@cuuxb.UUCP (Marc W. Mengel) writes:
>>	Actually, you can note the fact that whatever type the symbol has
>>    must be compatable with how it is being used, and check that against
>>    the actual declaration when you see it.  For example, if I see a
>>    function call:
>>
>>    intvar := funct( 5.0, "test", 7 );
>>
>>    I can note that funct must return a type that can be assigned to an int,
>>    and accept a floating point, char array, and integer argument;  then,
>>    when I see a declaration of funct, I can check against this usage, and
>>    determine whether the previous usage was correct.  While this may seem
>>    to be a lot of bookkeeping, it seems to me the gains in speed for a 
>>    one pass compiler are sufficient to warrant it.  I may also need to
>>    back-patch some appropriate type conversions (i.e. integer->real, etc.).
>
>And what if it turns out that funct is really a type, and that statement
>should have been flagged as a syntax error?  

	Then as soon as you realize it, you should print out the fact that
a syntax error was detected, in the original place.  Sure, this may mean
that syntax errors are printed out of order by line number;  but that is
not really a problem.

>I think that if you really
>look carefully at what your proposal would do to calling sequences, and
>the amount of backpatching that would be needed, you'll agree that it's
>impractical at best.

First; I was not argueing practicality, I was arguing possibility.  I
realise that the amount of work required to do this properly in a
strongly typed language like Modula2 is probably large.  The real
question is: does this extra work exceed the slowdown of using a
2-pass compiler?

One simple method of dealing with the backpatch problem, is to compile
any expression you cannot resolve as:
	jsr backpatch<nnnn>
and save up the code and its context someplace.  Then at the end of
the compilation module, put down each backpatch<nnnn>, and generate
the code you could not before.  if you can't NOW, having seen the
entire compilation module, you have a bona-fide error, and can report
it (generating an out of order by line number error message).  If
you can compile it now, you can plunk the code down followed by a
return from subroutine call, and fix the address in the jsr backpatch<nnnn>
call.  The only expense is the "save up the code and its context" part.
I am presenting the proposition that this may be, although costly, still
cheaper than a second pass.

Yes, FORWARD declarations are simpler, and probably a better solution, I
was making a purely "religious" comment on the statement that it was
*impossible* to make a one-pass full-Modula2 compiler.
>
>Rich



-- 
 Marc Mengel
 ...!ihnp4!cuuxb!mwm

Declaration after use is an abomination, and should not bear consideration.
FORWARD is acceptable for mutually recursive procedures.

What has been omitted from this discussion is that one-pass restrictions would
prevent mutually importing internal modules.  This is a real and difficult
restriction, which will force one to promote internal modules to become
library modules sooner than one might wish.

The question is can we live with such restrictions to gain compilation speed.
My opinion is yes.  And yours (pl.)?

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

 Re: Declaration after use is an abomination, and should not bear
     consideration.

I can't accept this.  After many attempts to settle upon a good rule for
arranging (procedure) declarations in a logical and natural order, I've
concluded that there is no single best arrangement.  One that often works
well for me is simple alphabetical order, sometimes with the public entry
points sorted into a separate series at the beginning.  In other
situations, a top-down arrangement of procedures seems best.  In either of
these arrangements, a lot of declarations occur

The fourth pass of the old ETH compiler had mutually importing internal
modules, both at the outer level of the enclosing implementation module.
As the compiler could compile itself, I am nonplussed that its compilers
derived from it could not.

I would note that if two internal modules are mutually importing, that both
may not have code in their module bodies (the initialization sections, not
procedures), as it is a case of circular initialization.  A degenerate
example might be

  MODULE A;
    MODULE B;
      IMPORT c;
      EXPORT b;
      VAR b : CARDINAL;
      BEGIN
        b := c + 42
        END B;
    MODULE C;
      IMPORT b;
      EXPORT c;
      VAR c : CARDINAL;
      BEGIN
        c := b + 42
        END C;
    END A.

randy