Re: Teaching compilers backwards?

I'm at the stage where I'm doing compiler construction and I agree.
Compiler courses are very unsatisfactory because we don't write real
compilers or really learn anything. By the time the exam is "last
week," everything is pretty much forgotten. The course runs way too
fast and everything is vague and abstract. If we're lucky we'll do a
stupid YARPNC (Yet Another Reverse Polish Notation Calculator).


I have issues with the textbooks too. They are boring and extremely
hard to decipher. That god awful textbook by Aho (the "Dragon Book")
is about as exciting as "Gone With The Wind." It's full of symbols and
squiggles that we've never come across before and doesn't adequately
cover this stuff. It's like learning a foreign language and suddenly
being immersed in it after learning only a couple of words. They tend
to merge and vibrate on the page after a while... what the hell is
wrong with plain English explanations? Why not more concrete examples
instead of:


S -> aBc
B -> ScB|e


WOW! That's a real language. Not.


We're thrown into all this stuff about LR and LALR and we're not
really ready for it. Despite all the efforts of the teachers and our
study guides and textbooks, I had to resort to USENET to try and make
sense of all this stuff. Nobody explained to me that a lot of compiler
and grammar/language development is trial and error and heuristics.
And there I was desperately trying to understand the elusive hard and
fast rules like mathematics.


In contrast, like Michael said, I did go and dig through GCC and
learnt about building parse trees and generating machine code. I saw
this before the compilers course made any mention of ASTs and stuff. I
know enough to feel confident in going ahead and writing my own front
end for GCC for a new language (as long as a grammar exists, I could
probably write the grammar if I really tried). I know where to look in
the sources if I get stuck on something. GCC is a huge and
complicated software system but if you stick at it longer than a
couple of days it starts to make sense.


Compiler courses should be spread across two semesters like Michael
said. I suggest the textbooks for the first two courses be Michael
Scott's "Programming Language Pragmatics" and a practical,
LL/recursive descent focused textbook like Pat Terry's "Compilers and
Compiler Generators" (uses Cocol/R) or Seth D. Bergmann's "Compiler
Design: Theory, Tools and Examples" (Java edition uses SableCC, which
has a shorter learning curve than most compiler-compilers.) Other good
choices are "Writing Compilers and Interpreters" by Ronald Mak,
"Constructing Language Processors for Little Languages" by Randy
Kaplan and "Programming Language Processors in Java: Compilers and
Interpreters" by David Watt. The second course can use a textbook like
"Modern Compiler Design" by Grune or "Advanced Compiler Design and
Implementation" by Steven Muchnick.


Over the year, GCC/lcc/xbasic/freepascal/whatever can be useful case
studies.


Johnathan


Michael Ross wrote:
> I've long maintained that teaching compiler construction in a one semester
> course is doomed to fail. The kids simply can't learn fast enough. ...
[Maybe it's a cultural thing. Americans think Gone with the Wind is a
good read, and I never had trouble with a one-semester compiler course.
We had a lot of latitude, so I wrote an APL subset to Basic translator
in Trac. It worked. -John]

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