Re: JavaCC in teaching

Etienne Gagnon wrote:
... but I sincerely think it
> presents a much cleaner separation of generated vs programmer-written
> code within a very nice OO framework for developing interpreters and
> compilers.


It may be easier to understand interpreters/compilers when using OO +
frameworks, but I wonder how much of that knowledge carries over into
the real world.


IME/O, compile-time performance requirements are going to drive you to
discard most OO features relatively quickly. I am aware of at least one
(academic-ish) project where a compiler was written in C++ using what
I'd call a reasonably strict OO approach (iterators, type hierarchy for
constants etc.); it took them something like a couple of hours to
compile gcc, even at the equivalent of -O1.


Also, memory usage (suprisingly!) becomes an issue. Now that whole
program optimization is becoming possible for large programs, we're
seeing cases where memory becomes a performance bottle neck.


I suspect that a lot of compiler course focus on parsing and on simple
AST based optimization [as do most of the questions raised on
comp.compilers!] I wonder how much of this is actually useful in the field.


Among other things, most front-ends I've seen are hand-written recursive
    descent parsers. This is for two reasons:
- for commercial parsers for real languages, such as for C and FORTRAN,
I suspect it is because of the error reporting requirements and language
corner cases.
- for internally designed little languages, one can design the grammar
such that a recursive descent parser is adequate.

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