1. SLE@UiB Avatar SLE@UiB
  2. inf225
  3. inf225

Wiki

Clone wiki

inf225 / 2017 / Term Project

View History

Purpose

  • Learn – Gain extra insight into something that interests you.

  • Do – Get (good or bad) hands-on experience with tools.

  • Share some of your new insight with the other students.

Grading

At the final exam, you will be asked to show stuff from your term project, and reflect on what you've learned and the choices you made.

Time Frame

  • Until Friday, November 11th: Think about what to do, try to decide on something, get started

  • Make a decision together with Anya, either in person or via email/facebook (more likely, due to travelling).

  • November/early December: Working. If Anya hasn't given you a paper or book chapter to read, nag her until you get it.

  • Check in with Anya and/or Anna for advice and follow up every week.

  • Finish some time around December 10th, so you have time left over to study for the exam and other exams. You should expect to have a prototype at least two weeks before the exam, which will be some time in December (we'll make Doodle and pick a date that suits everyone).

  • Do a short show-and-tell to the other students. You don't have to have your whole stuff finished to do this, just show an interesting aspect, or some insight about the technology you're using.

  • You can work on your project until the week of the exam, though you should have a prototype ready before then.

Organisation

The project is individual, but with a certain level of cooperation allowed. For example, a small group could work on the same language, but deal with different components of the implementation. Discussion is OK. Again, the purpose is to learn something. (You should of course be prepared to explain any part of your own code and design. Normal rules for copying/plagiarism/cheating apply, as always.)

You select what project to work on and what technology to use – though you should get it approved by Anya before you start. Obviously, it needs to be relevant for the course.

Technology Choices

  • You choose! (within reason)

  • Nice if several similar project use different technologies

Typical choices:

Project Ideas

0. Particular Project Ideas

(Based on Anya's and Anna's current hobby research ideas.)

  • Web-based syntax/grammar explorer: create a web app that lets a user explore grammars and parse trees. E.g., upload/enter a grammar and a text, visualise the parse trees and link it back to the text and the grammar. Anya has code that can build parsers and give access to a serialized representation (e.g., JSON) of grammars and parse trees and such.

  • Generate API usage info from Java code. You can load class files and examine what method calls they make (Anya has code you can start with). The idea would be to (perhaps later) see how API usage changes over time.

  • Visualise a (virtual) machine, with a graph for the instructions and the objects in memory, so students can learn what happens in a computer while a program executes.

  • Make a small visual language where you can draw objects and attach code to them. (Dan Ingalls is working on a system like this: Lively.)

  • Use the Java debugging interface to connect to a running Java program, and "audialize" its execution.

1. Programming Language Implementation

Implement (and design) a programming language. (This is the classic INF225 project; Lisp/Scheme is particularly easy.)

For a trivial design, you can do everything yourself. With a more sophisticated language, it makes sense to split the work into neat chunks. For example:

If multiple groups / persons work on the same or similar languages, it would be nice to use different technologies and see how the experiences differ.

2. Make a Domain-Specific Language (DSL)

  • Make an evaluator or a compiler (typically to a high-level language)
  • Or, embed the DSL in a language such as Haskell, Scala or Racket

DSL Ideas

  • 3D printing (not sure how this would work)
  • Graph/tree algorithms. For example; check out Nuthatch – a Java library for tree traversal that's just waiting for someone to make a nice DSL frontend for it.
  • DSL for programming lunar landers

3. Tree Walking

  • Implement something useful (refactoring? optimisation? analysis? using Nuthatch

  • You can pick up a paper about this on the shelf outside Anya's office.

  • Participate in actual research. No one knows how this approach works out in practice – your case study can help.

4. Code Formatting

  • Take messy code as input, produce beautiful formatted code

  • Maybe use the PGF framework (project page not filled in yet...)

  • You can pick up a paper about this on the shelf outside Anya's office.

  • Compare with other formatters, see how good yours is.

  • Participate in actual research. No one knows how this approach works out in practice – your case study can help.

5. Language Specification

  • Formalise the semantics of a language (perhaps a language someone else is implementing?)

  • You can use Prolog to make an executable specification. This could then be used to test the implementations (if someone has made an implementation).

Resources

Backend / Code Generation

Assembly Programming

ARM Architecture

JVM

Semantics

JIT Compilation

Projects from 2013

Updated