Re: JavaCC in teaching

Mayan Moudgill <mayan@sandbridgetech.com>
19 Dec 2004 23:50:50 -0500

          From comp.compilers

Related articles
JavaCC in teaching waldmann@imn.htwk-leipzig.de (Johannes Waldmann) (2004-12-16)
Re: JavaCC in teaching gagnon.etienne_m@uqam.ca (Etienne Gagnon) (2004-12-17)
Re: JavaCC in teaching demakov@ispras.ru (Alexey Demakov) (2004-12-17)
Re: JavaCC in teaching mayan@sandbridgetech.com (Mayan Moudgill) (2004-12-19)
Re: JavaCC in teaching desw@cogs.susx.ac.uk (2004-12-22)
| List of all articles for this month |

From: Mayan Moudgill <mayan@sandbridgetech.com>
Newsgroups: comp.compilers
Date: 19 Dec 2004 23:50:50 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: 04-12-065 04-12-075
Keywords: Java, courses, OOP
Posted-Date: 19 Dec 2004 23:50:50 EST

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.


Post a followup to this message

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