Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only problem with going backwards is that you are working from a drive-by spec at each step. You can tell students "this is the instruction set for the code you need to generate" and then "this is the intermediate language for the language you will parse."

None of the work is motivated concretely by the work of the prior step.

Fine if you are designing the representations for them, but I'm wondering how they would design an AST for a language they haven't seen or haven't thought about how to parse.

It would be an interesting experiment. If you were going to have them design the internal representations, you could have then move backward in a why that allows them to compile a family of languages. They could create something as general as the LLVM suite. :)



> I'm wondering how they would design an AST for a language they haven't seen or haven't thought about how to parse.

A third alternative would be to start in the "middle" with the AST, and go both forwards and backwards from there. :)

So, start with the AST as a given, or even have them design it, and use it to drive the design of the concrete syntax, static analysis, code generation, etc. At each phase, cover relevant concerns (i.e. "here's how to avoid shift-reduce conflicts in the concrete syntax").

I know nothing about teaching, so probably this wouldn't work, just speculation.


The motivation is the same as one gets from moving from C to C++; you start with a small language (in this case, assembly) and then build on top of it. I've tried this recently in my own course, and found that the morale boost from having something that actually ran and produced results that they understand significantly improved learning.

As for AST design, it is easier to design the AST first than you might think. Just ask the designers of Lisp.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: