TITLE: Lessons Learned from Another Iteration of the Compiler Course
AUTHOR: Eugene Wallingford
DATE: May 14, 2012  3:26 PM
DESC: 
-----
BODY:
I am putting the wrap on spring semester, so that I can get
down to summer duties and prep for fall teaching.  Here are a
few lessons I learned this spring.

•   A while back, I wrote briefly about re-learning
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2012-05.html#e2012-05-05T11_53_52.htm">
   the value of a small source language</A>
for the course.  If I want to add a construct or concept, then
I need also to subtract a corresponding load from language.
In order to include imperative features, I need to eliminate
recursive functions, or perhaps eliminate functions altogether.
Eliminating recursion may be sufficient, as branching to a
function is not much more complex than branching in loops.  It
is the stack of activation records that seems to slow down most
students.

&#8226;&nbsp;  Using
<A HREF="http://www.cs.uni.edu/~wallingf/teaching/cs4550/media/basics-of-compiler-design-mogensen.pdf">
   a free on-line textbook</A>
worked out okay.  The main problem was that this particular
book contained less implementation detail than books we have
used in the past, such as
<A HREF="http://www.cs.sjsu.edu/~louden/cmptext/">
   Louden</A>,
and that hurt the students.  We used Louden's TM assembly
language and simulator, and the support I gave them for that
stage of the compiler in particular was insufficient.  The VM
and assembly language themselves are simple enough, but students
wanted more detailed examples of a code generator than I gave
them.

&#8226;&nbsp;  I need to teach code generation better.  I felt
that way as the end of the course approached, and then several
students suggested as much in our final session review.  This
is the most salient lesson I take from this iteration of the
course.

I'm not sure at this moment if I need only to do a better job
of explaining the process or if I need a different approach to
the task more generally.  That's something I'll need to think
about between now and next time.  I do think that I need to
show them how to implement function calls in a bit more detail.
Perhaps we could spend more time in class with
statically-allocated activation records, and then let the
students extend those ideas for a run-time stack and recursion.

&#8226;&nbsp;  For the first time ever, a few students
suggested that I require something simpler than a table-driven
parser.  Of course, I can address several issues with parsing
and code generation by using scaffolding: parser generators,
code-generation frameworks and the like.  But I still prefer
that students write a compiler from scratch, even if only a
modest one.  There is something powerful in making something
from scratch.  A table-driven parser is a nice blend of
simplicity (in algorithm) and complexity (in data) for learning
how compilers really work.

I realize that I have to draw the abstraction line somewhere,
and even after several offerings of the course I'm ready to
draw it there.  To make that work as well as possible, I may
have to improve parts of the course to make it work better.

&#8226;&nbsp;  Another student suggestion that seems spot-on is
that, as we learn each stage of the compiler, we take some time
to focus on specific design decisions that the teams will have
to make.  This will alway them, as they said in their write-ups,
"to make informed decisions".  I do try to introduce key
implementation decisions that they face and offer advice on how
to proceed.  Clearly I can do better.  One way, I think, is to
connect more directly with the programming styles they are
working in.

~~~~

As usual, the students recognized some of the same shortcomings
of the course that I noticed and suggested a couple more that
had not occurred to me.  I'm always glad I ask for their
feedback, both open and anonymous.  They are an indispensable
source of information about the course.

Writing your first compiler is a big challenge.  I can't help
but recall something writer Samuel Delany
<A HREF="http://www.theparisreview.org/interviews/6088/the-art-of-fiction-no-210-samuel-r-delany">
   said</A>
when asked if he "if it was fun" to write a set of novellas on
the order of Eliot's
<A HREF="http://en.wikipedia.org/wiki/The_Waste_Land">
   The Waste Land</A>,
Pound's
<A HREF="http://en.wikipedia.org/wiki/The_Cantos">
   The Cantos</A>,
and Joyce's
<A HREF="http://en.wikipedia.org/wiki/Ulysses_(novel)">
   Ulysses</A>:

<BLOCKQUOTE><EM>
No, not at all.  ...  But at least now, when somebody asks, "I
wonder if Joyce could have done all the things he's supposed to
have done in Ulysses," I can answer, "Yes, he could have.  I
know, because I tried it myself.  It's possible."
</EM></BLOCKQUOTE>

Whatever other virtues there are in learning to write a compiler,
it is valuable for computer science students to take on big
challenges and know that it is possible to meet the challenge,
because they have tried it themselves.
-----