LARA

Labs 07: Compiler extension project

You have now written a compiler for Amy, a simple functional language. The final lab project is to design and implement a new functionality of your own choice on top of the compiler you built so far. In preparation for this, you should aim to learn about the problem domain by searching the appropriate literature. The project includes:

  • designing and implementing the new functionality
  • documenting the results in a written report document

This will be a team project for groups of 1-3. More details below.

This project has several deadlines to ensure that the project extension you pick is reasonable. Please read below.

Selecting a Project Topic

Deadline: Friday, Dec 7th 2018

This is a group project, so you will need to form a group of 1-3 people. You are of course encouraged to work together!

In the following document, we list several project ideas, but you should also feel free to submit your own by email. All groups will rank the projects in order of preference, and we will then apply a matching algorithm to assign them. Because not all projects are equally difficult, projects indicate the maximum size of a group that can take them. When selecting projects, make sure you respect this restriction. If you are a large group and fail to find enough large projects that interest you, you can suggest an extension to a smaller project, or as a last resort you can take two smaller projects and split.

Project ideas

Send Georg (georg.schmid@epfl.ch) an email titled “Project selection: sciper#1, sciper#2, sciper#3”, containing the names of the top exactly 5 projects you would like to do, in order of descending preference. We will do our best to assign you the projects you are most interested in.

You will need to base your projects on one group member's repository. Discuss among yourselves and decide which one is in the best shape, and, if you haven't already, create a Git repository to collaborate efficiently. Your email to Georg should thus also contain the URL pointing to your Git repository which we'll clone by the final deadline.

Project Proposal

When the bidding phase is over and a project has been assigned to your group, you should prepare an 8-10 minutes presentation containing:

  • a basic overview of the features you want to add to the compiler/language
  • some (short) programs highlighting the use of these features, with a description of how your compiler currently behaves on them (if it supports them at all), and how the improvements will change that behavior
  • a sketch of the changes you will make to each compiler phase and of the potential new phases you'll have. This should not be a complete implementation plan, but it should demonstrate that you understand how to tackle the problem you chose.

You will present your idea during the lab sessions on Dec 17th/19th/20th. We ask that you send us your slides the night before so we can streamline the presentation session. Please make sure to stick strictly to the 10-minute time-limit as we'll be on rather tight schedule.

Project implementation and report

Deadline: Jan 11th 2019 23h59

Your implementation and a report are due on this date, and both will be delivered using Git.

You are encouraged to use the following (LaTeX) template for your report:

A PDF version of the template with the required section is available here:

You can submit your report (PDF and optionally sources) under a toplevel directory called report. Additionally, you must include clearly specified runnable examples that showcase what your extension does under the examples directory.

Although you are not required to use this template, your report must contain at least the sections described in it with the appropriate information. Note that writing this report will take some time and that you should not do it in the last minute. This final report is an important part of the compiler project. If you have questions about the template or the contents of the report, make sure you ask them early.

A common question is “how long should the report be?”. There's no definitive answer to that. Considering that the report will contain code examples and a fairly precise description of implementation, it should probably be at least 3 pages. Less would be suspicious. 6 pages is fine. We will not complain for up to 10 pages if the content is meaningful, but extra pages by themselves do not make a report better, so please use as much as you need.