Assignment 3

Description

In this assignment you will design and implement a library for something fun, and write a program using your library. You can choose between three different projects:

• A board game library
• A make tool
• Something else

The assignment is done in the same groups as the previous assignments.

As with the previous assignments there are two parts, in the first part you will design the interface for your library and give a few simple example uses of the functions in the interface, and in the second part you will implement the library and a more ambitious example.

Project suggestion 1 - A board game library

Design and implement a library for describing board games.

To think about

• What kinds of boards do you support? A possible restriction is to only allow rectangular boards.
• How many players can play your games? Do you want to restrict yourself to two player games or allow an arbitrary number of players?
• Different board games have very different sets of pieces. How can you make the library parametric in the type of pieces? Maybe type families would make a neat solution.
• A central concept is that of a move. Try to come up with a nice, compositional way of describing moves.
• Another important thing is to be able to describe predicates on the board. For instance, to detect that a certain player has won the game, or to describe when a particular move is valid.
• Make sure you develop at least two example games in parallel with designing the library. That way you'll get quick feed back on how easy your library is to work with.

In order to play board games implemented using your library you need some kind of user interface. This doesn't have to be anything fancy and could be a very simple text based interface.

Project suggestion 2 - A make tool

Design and implement a library that will allow people to throw away all their old horrible Makefiles and replace them with Haskell programs using your library. A source of inspiration can be Neil Mitchell's 'Shake' (slides, video). If your library is heavily inspired from it, say so and motivate the differences from Neil's design.

To think about

• The key functionality of the make tool is that if you change a file it will only recompile the parts of a project that depends on that file.
• Identify the concepts of interest. These might be different depending on how you choose to structure your library. Some potentially interesting concepts are: projects, files, rules, patterns, and actions.
• Monadic or not? A monadic interface might be nice. Maybe you can borrow some ideas from the Replay monad?
• Parallelization. If you are careful not to make things to sequential you might be able to build parts of a project in parallel. Think about this possibility when designing the interface.
• You might want to allow parameters to your build scripts, for instance to choose a particular compiler. Think about how this can be done in a nice way.
• In a standard Makefile you can write general rules, for instance, how to compile a .c file into a .o file. The Makefile can then be used to compile arbitrary .c files which weren't known at the time the Makefile was written. Think about how to do this in your library.
• Compilation might fail. Make sure your library catches that.

The example programs for this project would be a set of non-trivial build scripts, either for real projects or for made up projects. Make sure to include examples for all of the fancy features in your library.

Project suggestion 3 - Something else

Come up with something interesting. Before starting on the assignment come see us (or send a mail) to get the go-ahead on your project.

Part I

Deadline: Wed Mar 2

The first part of this assignment is to design the interface to your library and give a few simple examples of how you envisage it being used.

The report should include a discussion on the various design choices you were faced with when designing the interface and motivations for your choices.

Part II

Deadline: Wed Mar 9

Implement your library. Of course, you are free to change the interface from part 1 if you think it's necessary, but if you do, make sure to include your motivations in the report.

You should also write an interesting program using your library.

Submission

Deadline

The deadline for part 1 is Wed Mar 2 and for part 2 Wed Mar 9. The final deadline is Wed Mar 16. (Please read the rules on what first and final deadline mean.)

Clean Code

Before you submit your code, Clean It Up! Submitting clean code is Really Important, and simply the polite thing to do. After you feel you are done, spend some time on cleaning your code; make it simpler, remove unneccessary things, etc. We will reject your solution if it is not clean. Clean code:

• Does not have long lines (< 80 characters)
• Has a consistent layout
• Has type signatures for all top-level functions
• Has good comments
• Has no junk (junk is unused code, commented code, unnecessary comments)
• Has no overly complicated function definitions
• Does not contain any repetitive code (copy-and-paste programming)

Submission

Your submission needs to include the following information:

• Your Haskell files (.hs or .lhs), containing your solution. Do not submit .o, .hi or .exe files!
• report.txt or report.pdf, a file containing documentation of what you have done.

Before you submit, please read the note on cheating.

You are supposed to submit your solution using the Fire system.

Note: You do NOT have to use zip/gzip/tar/bzip on your files! Just upload and each file that is part of your solution. Don't forget to submit when you have uploaded all the files.

To the Fire System

Good luck!