Each project has 4 team members. The project team elects a team lead.

Between October 25 and November 6, 23:59, the team lead puts the names of the team members into an eCampus discussion item, together with your first and second choice for the project. Projects are given out first-come/first serve. If you want more time to work on your project, secure it early. If you prefer to work with unmotivated strangers on a hard project, do nothing, and I will add you to the leftovers on November 7.

Projects 1 - 3 are due December 4, Projects 4 - 7 are due December 9.

1. There are two three-person teams, each of whom is doing this project.

   Team A: Tuan Minh Nguyen (team lead)

   Grant Callghan

   Lambert Fong

   Team B: Aaditya Bhatiya (team lead)

   Minh Chuong

   Derek Ng

   Add Hindley-Milner type inference to SL3. The Hindley-Milner algorithm uses unification to determine the types of variables, requiring no type declarations at all (even for recursive functions). Your team will read up on the algorithm, experiment with the ML language that makes use of it, and add an implementation to SL3 (which is modified to remove all : Type indicators).

2. Bogdan Komlik (team lead)

   Crystal Cheney

   Gavin Cooper

   Tom Skrainar

   Add lists and JavaScript-style object to SL2. Lists should simply support the head/tail/::/isNull operations. Your choice whether you implement them as pseudo-functions head(lst) or pseudo-attributes lst.head. A JavaScript-style object is a map whose keys are strings and whose values can be any type. For example,

   var car = { model : "Toyota Prius", year : 2008 }

   The values are accessed with the dot notation, such as car.year. Values can be functions. When such a function is invoked, the argument to the left of the dot is bound to this. For example,

   val account = { balance : 100, 
      deposit = { amount => this.balance = this.balance + amount }};
   account.deposit(1000);
   println(account.balance); // prints 1100

3. David Twamley (team lead)

   Devon Wright

   Shayne Bullington

   Rocky Khatra

   Add a debugger to SL2. It is easy and fun to add a debugger to an interpreted language. Your debugger should have the usual operations: Go one step, trace inside function call, skip over function call, skip to function return, inspect variables, show the call stack. Breakpoints would also be nice. A GUI is optional but highly appreciated.

4. Josh Moline

   Tuan Nguyen (#2)

   Timmy Yee (team lead)

   Miaoer Yu

   Add classes to SL4. SL4 is a simple compiled language, similar to C. Your team will develop a syntax for classes (which should not implement all features of Java classes; for example, public/private could be optional, and you should not support static fields/methods at all.) You will, of course, support instance fields and methods. Your SL4 compiler will produce bytecodes for Java class files. You need to detect syntax errors—any program that you compile without error must be loadable into the JVM.

5. Ian Macauley

   Ryan Aldana (team lead)

   Allen Lin

   Tatsiana Gomova

   Add closures to SL4. SL4 only has top-level functions. You should support nested functions as in SL2. You need to compile each closure into a separate class (just like Scala does).

6. Javier Arboleda (team lead)

   Paul Towyenis

   Jasson McMorris

   Richard Fleming

   Add a query visualizer to the Scala Prolog interpreter. You have the source code for a Prolog interpreter—about 200 lines of Scala code. Augment it to a tool that allows students to visualize which rules a query attempts, and what happens when unification succeeds or fails. The hardest part is the design of an effective visual representation. Pick what you like from SWI, and improve what you don't like.

7. Alex Tsui

   Anh Nguyen

   Kenneth Jung

   Ketaki Borkar (team lead)

   Add support for integers to the Scala Prolog interpreter. The Scala Prolog interpeter currently supports just lists. Your task is to identify a subset of the SWI Prolog integer operations, and add it to the Scala interpreter. You will want to implement as little as possible in Scala and as much as possible in a preloaded Prolog library. It is ok if the syntax isn't the same. For example, instead of M =< N, you can use le(M, N).