You are here:
(27 Nov 2007,
%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]]
ore topic actions
Topic revision: r8 - 27 Nov 2007,
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding UUCS?