On 4 Oct 2003 14:47:19 -0400, Rodney M. Bates <rbates@southwind.net> wrote:> Well, it seems like one obvious problem with this is that each> phase uses as input, the output of the previous phase. And what> that output is, both its format/syntax, and its deeper semantics, are> things a compiler course student won't already know. And explaining> that will considerably overlap just studying the previous phase.>> Andy Gill wrote:>> Has anyone ever taught compilers backwards? How did it work out?>>>> Traditionally, a compiler class starts with lexing, and flows downstream>> towards register allocation and assembly language generation.>>>> I am considering starting a compiler class with assembly language exercises,>> and having the students build a small compiler from the back, forward.

I don't have any experience teaching compiler construction, but an
alternative approach could be top-down, ie start with a simple
search/replace problem, then increase the gap. As the gap becomes
bigger, the need for a structured approach to the translation becomes
apparent. What at least would become clear is that 'translating code'
is not only 'real' compilers, translation happens in many forms.

For example (in an assembly-like language):

- have variables with a name (search/replace name to address-value)
- have loop statements (you need local labels to jump to)
- have expressions (a tree structure is needed(?))
etc

This can be seen as working backwards because you keep the target
language constant, but the problems (like above) are not really
related (as in the second problem can be solved by re-using the
solution to the first problem) at first sight.