CS 4550: Translation of Programming Languages

Opening Exercise: Debriefing the Project

Most semesters, we open the final exam session by debriefing the project. With five teams this semester and each having a lot to say, we skipped the debriefing. Feel free to read these notes from the last time we taught the course. You can also jump past it to the rest of the session.

First, I'd like each person to debrief the compiler project, answering the following questions:

• What was the easiest part of the project?
• What was the hardest part?
• Of which part of your program are you proudest?
• Which part of your compiler would you re-write first, if you had the chance to improve only one part?
• What would you do differently on your next project?
• What could I as instructor do differently to improve the course?

Your answers can refer to programming practices, languages, tools, project management, teamwork, course content, ....

Be as specific as possible. I'd like to use your answers to improve the course next time around.

... discuss...

A couple of ideas from our class discussion:

• What was easiest? I found this answer interesting and insightful: writing the 3AC generator, because the only abstractions we had to work with were ones we created ourselves (the AST and the 3AC code format).
• What was hardest? I found this answer interesting and insightful: the parser, because the parse table seemed easy to mess up and hard to fix.
• What can the prof do better? You liked the sequence of TM exercises that we did to launch learning for Module 5. You would like for me to create and run more exercises in, and near the end of, each session. You think they will help your learning. I will try to do this!

Some of my ideas:

• Create a more useful demonstration compiler, for the Day 2 sprint and as a running example throughout the semester. The Fizzbuzz language illustrates a lot of features, but it doesn't have variables or types (so there isn't much need for semantic checking), the grammar is almost too simple (so there isn't much to learn from its abstract syntax), and its output requires characters (which TM does not support).
• Discuss abstract syntax better and more concretely up front. Show an example and work through an exercise or two defining the abstract syntax for a grammar. For example, we could use the demo language to give an early, concrete picture of a parse tree and an AST.
• Put review and team work days to better use. Maybe trim some more material outside the scope of the project and use the time to discuss design and implementation in class.
• Reorganize codegen sessions a bit: talk less generally at a high level, and order topics with even more direct connection to day-to-day-project work.
• Unit testing. Unit testing worked well for a couple of last year's teams, when they had the time to do it. Maybe teams could use the two weeks before the project kicks off to research unit testing tools for their languages, get some practice with it, build it into their work flow. (Also, what about CS 3730?)
• Always in the mix: Use a parser generator to produce the parser. Use the freed time to expand optimization or even code generation.

A couple of valuable suggestions from previous class discussions:

• Project days. The course is content-heavy relative to some other project courses. Perhaps find a way to cut back on some content and build in several project work days, especially during the heaviest parts of the project.
• Increase the workload for Project 5. We discussed the goal of Project 5, the reality of this year's submissions, and how I might do a better job setting expectations. This might involve requiring more work; I'll have to think about it.

After working on a big project for the first time, or a big project in a new domain for the first time, we often realize how much we have to learn and figure out more about what to learn. Your feedback here is useful to me, but also to you.

Compiler Presentations

Each team presents its project and demos its compiler.

While watching the other team's presentations, please evaluate:

• the clarity of the content
• the organization of the presentation
• the appearance of the presentation
• the distribution of responsibilities
• the overall quality of the presentation

Overall, do you think that this presentation gave as favorable an impression of the project as possible, given the state of the compiler being presented? Why or why not? (Defend your answer!)

Follow-up after the final presentation: [ Well done. Your presentations improved nicely on those from recent semesters. ]

A Comparison of the Compilers

... in slides.

We looked at your compilers in terms of size, speed, and execution of some standards. I also include a couple of excellent compilers from past semesters, for context.

Three programs I like to use to demo the compilers every offering:

• euclid.kln
• sieve.kln
• is-excellent.kln

Do you remember short-circuit-evaluation?

or and and short-circuit evaluation when possible.

So:

• Does or short-circuit ?
• Does and short-circuit ?

Two programs I like to use to benchmark recursive functions:

• a program that only grows the stack
• a tail-recursive program that computes factorial

A new program!

• Is n a Carmichael number?

My Project Story

A phone call, April of my junior year. A team comes together.

Crunch time. A team falls down.

There are many ways for even a well-planned project to go wrong. Enjoy the moments when things go right. Life goes on either way.

Closing Exercise: Evaluating Your Team

I would like each person to comment on the contribution made by the members of his or her team:

• How well did the person fulfill his assigned role?
• How well did the person contribute to the overall success of the project?
• For a rating, give a score between 1-10 as a summary evaluation of the person's contribution. No two team members may receive the same rating.
• For points, divide the 100% available to your project among your team members according to what you think each person earned. Team members may receive the same numbers of points.

Your answers can refer to contributions learning Klein and TM, designing the compiler, writing the compiler, writing test programs, documentation teamwork, ....

Be as specific as possible. I will use your answers as a part of my evaluation of the project and my assignment of grades. Your answers will be anonymous, so you needn't refrain from speaking openly.

A Few Compiler Moments to Close

You may want to create your own language.     How I Came to Write D

You may want to extend your language.            Adding a New Statement to Python

You may want to do something all your own.    Alda: A Music Programming Language for Musicians

You may want to help program the future.         Programming the Quantum Future

And now you can. I really enjoyed working with you this semester. You can be proud of the software you created and of how you created it. Go forth and use your powers for good.