Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!caip!clyde!cuae2!ltuxa!cuuxb!mwm From: mwm@cuuxb.UUCP (Marc W. Mengel) Newsgroups: net.lang.mod2 Subject: Re: Single Pass Modula-2 Compiler Message-ID: <851@cuuxb.UUCP> Date: Thu, 9-Oct-86 16:45:43 EDT Article-I.D.: cuuxb.851 Posted: Thu Oct 9 16:45:43 1986 Date-Received: Fri, 10-Oct-86 08:18:08 EDT References: <12243102365.25.KURKURE@Sushi.Stanford.EDU> <841@cuuxb.UUCP> <8@f.gp.cs.cmu.edu> Reply-To: mwm@cuuxb.UUCP (Marc W. Mengel) Organization: AT&T-IS, Software Support, Lisle IL Lines: 61 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 and save up the code and its context someplace. Then at the end of the compilation module, put down each backpatch, 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 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