CPSC 311 Final Project

The goals of this project are:

• To deepen your understanding of programming languages.
• To put your programming languages knowledge into practice in a new, practical context (where the meaning of "practical" varies across project types).
• To share what you've learned with your colleagues.

You'll choose one of four types of project with which to meet these goals. We illustrate each area with a brief example below:

1. Make a change to the semantics (and possibly syntax) of an existing programming language to fix some problem you (or the language's community) perceives in that language.

   For example, in Java an interface cannot require constructors with specific argument lists from its implementors. Some Java libraries therefore include comments like: "all implementing classes must have a default constructor". In response, you might research how to alter the Java language (creating your Background Research Report), propose a sweeping change that would allow specification of required constructors (your "potential project" in the background report and your "reach" goal in the Project Proof-of-Concept and Plan), and then actually implement a restricted version in which an interface can be tagged somehow as requiring a default constructor (your "simplest suitable" project in the Project Plan and perhaps your Final Project). If an implementor does not provide a default constructor, the compiler (or your analysis) generates an error.

   Here are some search terms to consider: Java custom annotations, JastAddJ, PyPy and RPython (Ron Garcia suggested this fascinating blog post on RPython), LLVM, Soot for Java, Template Haskell, and Spoofax.

   You might also use Racket's syntax macros (or Scheme's or Lisp's) to extend that language.

   How should you find these terms? Consider this or this or even this. (Many of these search terms would also be relevant for the topics below!)

2. Apply an existing, interesting dynamic analysis or static analysis (type checkers are definitely included!) to a substantial program, illustrating the value of the analysis.

   For example, you could take a program in a "conventionally" statically-typed language such as SML, OCaml, or Haskell, and add more precise types that make the program pass a more advanced type system. For SML, you could use SML-CIDRE; for OCaml, Dsolve (though the authors of that tool seem to have moved on to Haskell); for Haskell, LiquidHaskell or the type system of Haskell (or rather, GHC) itself, which is full of all kinds of stuff that isn't in the "standard" language Haskell 98. (If you took the last route, you would need to start with a—possibly very old?—Haskell program that predates all of that stuff.)

   Or you might convert a JavaScript codebase into TypeScript, annotate and analyse a Java codebase with ESC/Java 2, or use Valgrind or maybe SAFECode to help some poor, benighted-and-therefore-not-already-checked (but widely used) Github project clean up its memory leaks (and prevent future ones, with SAFECode).

3. Create a substantial program in a potentially useful but unusual (not "mainstream"; ideally, not even close to mainstream) language that you have not already studied. Your program should illustrate the particular features and benefits of the language.

   For example, you might implement some interesting parallelizable task in Chapel. Your program needn't be huge or even really practical, but it should be more than a tutorial/demo, and it must illustrate why the language designers thought the language worthwhile to create!

   Here's just a few other search terms to consider, in no particular order: TypeScript, Adapton, Clojure, Typed Clojure, Scala, Factor, Erlang (but remember, CPSC 418 students: only if you haven't already studied it!), MetaOCaml.

   (New revisions of old languages are not completely ruled out, but you'll need to argue that you're using the new features in a particularly interesting, probably "non-idiomatic" way, and we still might reject your argument.)

4. Design and implement substantial extensions to the [Typed] Fun++ language, and/or substantial static or dynamic analyses for [Typed] Fun++.

   This builds on the work done in the regular assignments. The extensions could be mainly in the type system/type checker, or mainly in the dynamic semantics, or in both.

   The scope should be, very roughly, comparable to 2 assignments on the scale of a2 and a3. If you are extending the language, you must do more than describe a set of features and code up something that "seems to work". In particular, you should precisely specify what the language extensions should do, most likely by writing rules. You certainly don't need to have this done in your project proposal; you should think of it as part of your code.

    

Of these project types, type 1 is probably the "hardest", but it really depends on the specifics.

You might also find some good ideas in Episode #5 and the first half of Episode #6 of the CS Education Zoo. (If you think these might be helpful, be sure to browse the "shout-out" links on the Zoo website.)

The project is in six steps, each with a deliverable. Finish the first four steps for the 80% level. Finish the first five for the 90% level. Finish all for the 100% level. The steps and their deliverables are described below. The deadlines for these steps are posted on the course website, or check them using handin.

Each step has a number of points associated with it. Your raw mark will be the sum of the points you get divided by the total points available in the steps required for your chosen level. Your final mark will be the raw mark scaled to the percentage for your level (i.e., 80%, 90%, or 100%). Thus, your mark can go down somewhat if you attempt but do very poorly on later milestones. (Note: in our [Steve Wolfman's] previous experience this doesn't happen if the team puts in real effort at the milestones.)

Every item in the marking scheme is worth 4 points. These 4 points will be allocated according to this scale:

4 points

item entirely satisfied and well done

3 points

item largely satisfied, perhaps with minor issues

2 points

basic goals of item satisfied, perhaps with substantial issues

1 points

some worthwhile, comprehensible effort toward satisfying the item

0 points

no real comprehensible effort toward satisfying the item

EVERY member of the team submits an identical plain text document named project-commit.txt to the handin target project-commit with the following form completed:

Team Member Names:

Team Member Student IDs:

Team Member ugrad.cs.ubc.ca Logins:

Initial level commitment (80%, 90%, or 100%):

Tutorial time that at least one and ideally all members will guarantee to attend
each week:

3+ hours weekly that the group guarantees EACH OTHER to be available
to meet (face-to-face or at a distance):

Three one-sentence ideas the team might pursue for the project:

1. 

2. 

3. 

This deliverable should be quite short.

Once we have the deliverable, we'll assign you a project facilitator from the CPSC 311 staff. From then on, you can direct questions to that facilitator, work with them to help you stay on track, and start figuring out how they interpret the project guidelines and marking scheme so you can get a great grade!

4 points

Submission format is correct, e.g., all members submitted identical plain text files on time with all required fields complete.

4 points

Proposed project(s)-of-interest show effort at exploring the proposed options and potential of growing into a proposal.

This milestone (project-commit) may not be resubmitted at a later time.

The deliverable is the report itself in PDF format. Choose any professional-looking format, such as the ACM proceedings format used for many Computer Science conference papers. (Don't miss the Word template if you wish to avoid LaTeX. If you don't wish to avoid LaTeX, you could also use Joshua's purple style, but don't expect great technical support.) Include a title for your project (prefaced by Proposal:), names and contact information for your team members, and everything else needed to fulfill the description above and marking scheme below. The document should be named project-proposal.pdf and handed in by ONE team member to the target project-proposal. (Subsequent resubmissions use the same filename but later milestones' handin targets. Only resubmit the file if you wish to be re-marked!)

4 points

Submission format is correct, e.g., ONE copy, submitted by one team member, on time.

4 points

The proposed project topic illustrates how it meets the requirements of its project type. You must describe how it could be a full 100% project, even if you're aiming for 80% or 90%.

4 points

The proposal lays out a clear, low-risk approach to meeting the 80% level project requirements.

4 points

The proposal lists a good set (at least three) of starting point documents for the team to work from as they approach their background report.

This deliverable is limited to 4 pages (with reasonable font/margin sizes, e.g., as in the ACM format above). We prefer a significantly shorter document, however. Practice brevity! Shoot for 2.5 pages.

This milestone, project-proposal, may be resubmitted once (at the next milestone) for full credit as long as the team earned at least 8 points on the first submission of project-proposal.

The deliverable is the background report itself in PDF format. Continue to use a professional-looking format and include a project title (prefaced by Background Report:), names and contact information for your team members, and everything else needed to fulfill the description above and marking scheme below. Do not include your proposal in this document, although you're likely to include elements from it! The document should be named project-background-report.pdf and handed in by ONE team member to the target project-background. (Subsequent resubmissions use the same filename but later milestones' handin targets. Only resubmit if you wish to be remarked!)

4 points

Submission format is correct.

4 points

Writing is professional (particularly: clear, concise, and easy to skim for key information).

4 points

Sources are cited appropriately throughout, both when quoted directly and when summarized or used as supporting evidence. (Note: where you quote sources, you must put quoted text in quotation marks (or otherwise clearly set off) with a citation. However, we generally prefer to read your summary and discussion over reading large sections of quoted text! Plagiarism will result in a 0 for the project and disciplinary action. Any clear, professional citation/bibliography format is fine.)

4 points

Overview of project topic is clear.

4 points

Value/importance/impact of project topic is clear.

4 points

Project topic is well-situated in its context (i.e., similar languages, analyses, or language features, depending on your topic).

4 points

Novel technical aspects of the project topic are summarized using appropriate programming languages terminology. (Please do not appeal to every term you've learned! Instead, use the skills and mindset you've developed in CPSC 311 to understand your project topic. The technical aspects you describe should include any needed for the project proof-of-concept and plan, even if you're stopping at the 80% level.)

4 points

Potential project—the one you'd do for the 100% level—is described in the context of the project topic. (Even if you're stopping at the 80% level, use your vision for the 100% level to structure your project topic discussion throughout!)

This deliverable is limited to 8 pages (using reasonable font/margin sizes). However, shoot for 5 pages.

This milestone, project-background, may be resubmitted twice (at the following two milestones not counting the poster) for full credit as long as the team earned at least 12 points on the first submission and at least 16 points on the first re-submission.

The deliverable is a report on the plan and proof-of-concept in PDF format. Continue to use a professional-looking format and include a project title (prefaced by Plan/Proof-of-Concept:), names and contact information for your team members, and everything else needed to fulfill the description above and marking scheme below. You SHOULD integrate your background report smoothly into this document, since it includes the introduction of your project topic! You need not include every word or even the same structure as your background report, however. The document should be named project-plan-proof.pdf and handed in by ONE team member to the target project-plan-proof. (Subsequent resubmissions use the same name but later milestones' handin targets. Only resubmit if you wish to be remarked!)

4 points

Submission format is correct (e.g., the Proof-of-Concept and Plan discussion integrate well with the existing report).

4 points

Proof-of-Concept documentation is sufficient for others to recreate the proof-of-concept without serious difficulties.

4 points

Proof-of-Concept suitably demonstrates—at a simple but functional level—the individual technical abilities needed for completion of the project (i.e., connects to project plan below!).

4 points

Project plan presents a plausible low-risk, "simplest suitable" approach to meet the team's core project goals. (Explicitly describe your core goals, and keep them sufficient but manageable!)

4 points

Project plan presents a plausible higher-risk, "reach" approach to meet the team's full project goals. (Explicitly describe your full goals! Make these ambitious but conceivably achievable.)

This deliverable is limited to 8 pages (using reasonable font and margin sizes, e.g., as in the ACM format above). Yes, this is the same limit as for the background report and may require streamlining that report. We think 6 pages should be ample, but use all 8 if you need them. (As with your poster: images, diagrams, screenshots, and the like are valuable communication tools!)

This milestone may be resubmitted once (at the final project milestone) for full credit as long as the team earned at least 8 points on this submission.

Your deliverable is the poster and its presentation on the last day of class by at least one team member at a time—"tagging off" to enjoy the posters and complete required peer reviews. We recommend printing out about nine or ten 8.5x11" pages to tape up as a poster. We'll bring the tape! Include a project title and names of your team members (in a big font!), and everything else needed to fulfill the description above and marking scheme below.

Several students will be assigned to review your poster on the scale indicated below. Your mark will be the median of your peer-review marks. Please use the same title you submitted for your background report milestone (without the Background Report: preface). Your reviewers identify your poster with that title.

4 points

Presents information in a clear format.

4 points

Makes the value/importance/impact of the project topic clear.

4 points

Provides me with the foundation I need to learn more about the project topic.

4 points

Makes me interested in learning more about the project topic.

4 points

Poster ranking. (Marked as: 4 points for excellent, 3 points for very good, 2 points for good overall, 1 point for poor overall, 0 points for missing.)

4 points more will be allocated based on every member of your project team filling out their peer evaluations fully and thoughtfully (unless excused by the course staff for, e.g., illness).

This deliverable is not handed in (but we'd love to be sent a copy!). We can't promise any more than a one meter by one meter space for your poster. (We will try to provide more space for large posters or laptop demos and the like, but we cannot promise anything!)

Obviously, there's no resubmitting this one!

The deliverable is your full project report in PDF format. Continue to use a professional-looking format and include a project title, names and contact information for your team members, and everything else needed to fulfill the description above and marking scheme below. You SHOULD integrate your background report, plan, and proof-of-concept smoothly into this document but needn't include every word. The document should be named project-final.pdf and handed in by ONE team member to the target project-final. You should then all do a happy dance, record it, post it to YouTube, and link to it on Piazza, but whether you do or not is unmentioned in the marking scheme.

4 points

Submission format is correct (e.g., the full project integrates well with the existing report sections).

4 points

Full project description appropriately illustrates what the team has accomplished in completing the project.

4 points

Full project description documents the project well enough for the committed reader to recreate any particularly difficult technical details. (Note: the "committed reader" worked through your proof-of-concept and is willing to spend time with resources you point them to in order to understand ancillary concepts.)

4 points

Full project clearly addresses the core goals laid out by the project plan.

4 points

Full project either clearly addresses the full goals laid out for the project plan or presents a well-informed discussion of what would be required to achieve these goals.

This milestone may not be resubmitted. Instead, just enjoy the final exam!