Re: Why separate the lexer and parser?

hbaker@netcom.com (Henry G. Baker) writes:


>The IBM 1401 Fortran compiler had ~100 (one hundred) passes in order to
>compile Fortran in to 1401 machine code. It stored the program in memory
>and passed the code of the compiler against it from a tape drive. Given
>the technology of the time, it was a relatively fast solution to the
>problem. I've been waiting for someone to claim that this is the _best_
>way to organize a compiler on today's machines. :-)


Okay, I'll have a try.


Five years ago, and in C/C++/Ada, using lots of passes was a bad way to
go. It involved lots of redundant data structure traversal and weakened
performance in lots of ways. On the other hand, passes often used similar
data structure traversals - each one computing some piece of information
or checking some aspect of the program.


In some ways, using several passes (not 100 though) is a good way to write
a compiler since that may reflect the way one thinks about the
organisation of the compiler. For instance, it may be convenient to think
about the compiler as doing parsing, then doing type checking, then data
flow analysis, then code generation, peephole optimisation, and so on.


Using modern declarative languages (like Clean, or Haskell), it is
possible to write the passes of a compiler in such a way that
deforrestation and such source-level transformation techniques can
condense the passes and yield a program that performs only a small number
of passes. The result is (hopefully) that one can write the logically
separate components of a compiler separately, and have the compilation
environment interleave them for you. Much more maintainable; much cleaner.


So there you go. I don't know how much source level transformation is
available in language implementations, but certainly a trend towards such
techniques is something to look forward to as you run those core files
through gdb....


Thomas
--
Thomas Conway conway@cs.mu.oz.au
--

Return to the comp.compilers page.
Search the comp.compilers archives again.