Home
Student Projects

Fosa
%TOC%

---++ Assigned Projects

| *Students* | *Project* | *Supervisor* |
| John+Mark | 4. Ruler code generation | Atze Dijkstra |
| Sander+Thomas | 5. Recursion pattern analysis and feedback | Stefan Holdermans |
| Michiel + Eric | 3. Repair directives | Bastiaan Heeren |
| Kasper + Gideon | 1. Type inference directives | Jurriaan Hage | 

---++ Description

The following projects are all rather summarily stated. 
All projects will be discussed in the introductory lecture.
More details will become available after pairs have been
assigned to the projects.
Specifically, what it takes to pass the assignment, and what it takes
to excel in a given assignment.

These projects are a substantial part of the course, counting for 40% of your final grade.
You will (both) have to spend approximately 100 hours on it: this estimation includes preparing
and attending of presentations, meeting with the supervisor, writing documentation, etc.
Each pair of students will be assigned a supervisor who will monitor your progress and answer your 
questions during a weekly meeting. Some of the projects below mention a supervisor, but might change
at some point. Your task is:

   * Foremost, to investigate and evaluate the approach sketched in your project's description. Study 
     related material. Own contributions to the project will be rewarded.
   * You are strongly encouraged to implement and test ideas yourself.
   * In a two-hour presentation you have to explain the problem, present solutions and results, and reach
     a conclusion.
   * Finally, submit your code and an accompanying document describing results, contributions, and conclusions.

---+++ 1. Type inference directives

This project may contain any of the following tasks,
make a .type file specification for a combinator language,
implement type inference decision trees into the Helium compiler,
and finally to consider and implement useful abstractions for
.type files.

Supervision: tba

---+++ 2. Type class directives

Investigate the use of invariants for the class system specified
by means of type class directives, based on a paper on this subject. 
Feasible parts of this specification need to be found and implemented.
The Top framework is taken as a starting point, inspiration can be found
among tools such as BANE.

Supervision: tba

---+++ 3. Repair directives

Repair directives are a new form of specification to have the compiler
generate correct versions of a program when a type error occurs.
Your task is to try out new transformations, study their effectiveness by applying them
to our base of logged programs and determine the right cost functions
to obtain the `optimal' solutions.

Supervision: [[http://www.cs.uu.nl/people/bastiaan/][Bastiaan Heeren]]

---+++ 4. Ruler code generation

The Ruler language specifies type rules and can generate Attribute Grammar (AG) code implementing such type rules.
Our AG system then generates Haskell from the generated AG code.
Mapping to AG imposes restrictions on type rules.
The project task is to eliminate some of these restrictions by directly generating Haskell.

Supervision: [[Atze.WebHome]]

---+++ 5. Recursion pattern analysis and feedback

Detect recursion patterns in a programs (a recursion pattern that
can be implemented by map or foldr) and to generate feedback to
a programmer how he can modify his program to use these standard
function and obtain the same result.

Supervision: [[http://www.cs.uu.nl/~stefan/][Stefan Holdermans]]

---+++ 6. Interactive feedback for type inference

Build a tool that can answer questions about the type of identifiers
in the program, ask the compiler to explain why a type is of a given form,
and to explain where the type error can be. The tool should be able to answer
such questions for type correct and type incorrect programs.
There exsist already tools of this sort, such as Chameleon, which can
serve as a source of inspiration.

---+++ 7. Error messages for phantom types programming recipe

In case that phantom types (developed by Daan Leijen) are used
to encode a class hierarchy, or the relation between a widget
and its attributes, details of this encoding are often present
in the error messages, and thus do not properly explain 
what mistake was made. Your task is to improve the situation, within
the context of a library such as HaskellDB or wxHaskell. You will be testing
your 'theories' on a lightweight library to keep things simple.

Supervision: [[http://www.cs.uu.nl/people/bastiaan/][Bastiaan Heeren]]

---+++ 8. Empirical study of Helium programs

Together we determine a number of hypotheses about the programming behaviour
of students, or the effectiveness of the Helium compiler in providing useful
feedback. Using Peter van Keeken's library there hypotheses need to be
investigated, by querying our database of logged Haskell programs and
finding support for or evidence against a each of the hypotheses.

Supervision: [[Hage.WebHome]]

---+++ 9. Ruler conditional type rules

The Ruler language specifies type rules which may overlap in the sense that a generated implementation
cannot choose between rules.
The project task is to design and implement a Ruler extension which allows explicit specification of the condition to be used by
the generated implementation to choose between otherwise overlapping type rules.

Supervision: [[Atze.WebHome]]