Mini Projects
Cco
General project information
Submitting
General info
2010/2011 edition
All should be submitted via the submit system at
http://www.cs.uu.nl/docs/submit/
as a single zipped file archive on the relevant deadline,
11:59pm.
Your submission
- The source code of your mini project implementations which must include
- UUAG sources.
- Haskell sources not generated by the UUAG system.
- Documentation in pdf format and the original text for documentation.
- A
README file (see later)
- All the code of your implementation must be documented; you must explain the design of your solution, the interface of functions, the use of attributes (when attribute grammar is used). Documentation must be in pdf format. Use the following tools for documentation:
- haddock; most appropriate for generating online doc for Haskell code.
- lhs2TeX; most appropriate for literate programming style for arbitrary program code, generating latex documents describing your code. See also CourseResources.
- TeX tools.
- In the
README file (in plain text format) you explain
- what functionality you have implemented,
- which versions of which compilers are needed to build your code,
- where the starting point of the design documentation is to be found.
- Your
README file should list the team members involved and should contain detailed instructions on how to build and use your programs.
- Use a makefile for the (low level) building instructions. The makefile by defaults builds the programs and has a separate entry for building the documentation.
- Also see the project descriptions for additional requirements.
Criteria and grading
Grading of the mini projects will be done using the following criteria, on top of constraints mentioned earlier on this page:
- The explanation of your design and implementation must be clear enough to not need actual inspection of implementation code for understanding the design and implementation.
- The implementation must compile & run without errors, and pass tests as specified by the project description.
- The design and implementation must be the simplest possible.
In other words: if you choose an implementation with difficult to explain parameters and structures, which you also do not (and most likely cannot) explain, then this will guarantee a low grading.
Working in teams
All projects are done in teams of two participants.
You are free to discuss at liberty about design and implementation ideas (because the necessary explaining helps you understand),
but you may not share between teams the code and explanation you submit and work on (this is considered fraud, and it does not help to
really understand),
with the exception of supporting material (such as makefile).
A team size of two helps you because you both have someone available to check your ideas with, yet at the same time prevents you from escaping the actual work which needs to be done.
The latter is important, because doing the mini projects constitutes the major part of becoming familiar with the course material and in that way is the preparation for the exam, which is a check on having acquired the knowledge explained in the course.
Submission of work is done per team.
Peer reviewing
Each team reviews the work done by other teams on a weekly and per lab exercise basis. At the lab session after the first lecture of the week we'll start by peer reviewing: each team has written on a single (or somewhat more, if necessary) A4 page their design for the solution of the lab exercise, available in printed form so another team can review it. That other second team reviews the design, asks for clarification, finding potential problems and limitations, etc. The purposes are (1) to start early with writing design documentation and think about the lab exercise, (2) to understand the problem better by looking at somebody else solution, (3) to facilitate class discussions about various ways to solve the problem at hand. Similarly, each lab exercise submission is peer reviewed, taking into account the grading criteria, leading to written feedback for both the reviewed team. Both this feedback and the submitted solution are used by the teacher for grading.
Mini Project A: BibTeX2HTML
The aim of this mini project is to implement a suite of small command-line utilities for processing bibliographic databases in BibTeX-format and producing logical documents in HTML-format.
Project description
Mini Project B: T-diagrams
The aim of this project is to implement a typed domain-specific language for T-diagrams.
Project description |
Project distribution
Mini Project C: Static-link optimisation
The aim of this mini project is to implement a small optimisation in a supplied code generator.
Project description |
Project distribution
Mini Project D: Type reconstruction
The aim of this mini project is to reconstruct explicit type annotations from implicitly typed lambda-terms.
Project description |
Project distribution
