Lab 4 is an open-ended lab in which you can design and implement your own mini project. The idea is to give you the freedom to explore Haskell in a direction of your choosing, if you so wish.
The project should take you around 20 hours of work working in a group of two, so it is best not to choose something too big; make sure that if you choose an ambitious project you should be able to demonstrate your progress even if the whole code is not complete.
For those of you who don't like the uncertainty that comes with such freedom,
below we have suggested a complete "standard lab".
Below you will also find some further ideas
that you can use as the basis of your project. Some of these come from labs from this course or other courses. You won't be able to assume that we are familiar with all these labs however, but we will help if we can.
Guidelines for your projects
From our previous experience we suggest the following guidelines in choosing and developing a project:
GUI libraries are often difficult to install (they are very platform specific) and GUI programming is not very functional. We suggest that you minimise this. We recommend using Haste for your GUI needs -- if any. Other recommendations for simple drawing and animation include Gloss and HGL (2014-12: I tried to install using cabal-install on my up-to-date Mac and they failed, but on other systems you might get lucky.).
Try to structure your project plan in stages so that you can have a "complete" project even if you do not manage to achieve all of your goals.
- Unlike with the other labs we might not be able to help you with the specifics of libraries and tools that you might want to use. Fortunately the online Haskell community is a helpful bunch. There is also a Haste google group and an IRC channel (#haskell-haste @ Freenode ).
What we expect to see in a project
We expect to see functional programming demonstrating:
- good functional style, including appropriate use of higher-order functions
- appropriate modelling and use of data structures,
- appropriate use of property-based testing with quickCheck,
- clean separation between functional code and IO.
Projects will be presented with a 5 minute oral presentation (a projector will be available) explaining what the project is about and giving a quick demo. The code should be uploaded to Fire in advance so we can have it ready to browse during your presentation and can ask questions about the code. Be prepared to highlight and explain the more interesting/challenging parts of the code!
Any code which is imported or adapted from another source must be clearly acknowledged, even if it is your own earlier work.
- Submit short proposal: latest on Monday in Week 6 (2016-12-05)
in the Fire system.
If you take the "standard lab" then you just need to say this.
Otherwise just send a sentence or two about what you want to do.
When accepted, you will be mailed a link to a sign-up page for your
presentation during Wed-Fri in Week 7 (14-16 December 2016).
Upload project source code to Fire (and any other supporting documents
if you have any). The deadline for uploading your project is
midnight on Wednesday in Week 7 (2016-12-14)
or 30 minutes before your presentation -- whichever one comes first.
Remember that you are expected to work in pairs and submit via
Fire in the usual way.
Some Project/Lab Suggestions
The following are a list of suggestions -- old labs or labs from other courses -- which you can use as the basis for your "project".
The Standard Lab.
This is a complete lab description in standard form. The description is split into several parts but you must submit the whole lab.
Most students who choose this lab in 2015 were happy with their choice.
The 9-men-morris game.
Many small games make for nice mini projects. One example is 9-men-morris described in this course lab.
(You can play online).
This looks like a good level of difficulty, although the code from the instructor does not look like she is experienced with Haskell (e.g. using numbers and characters instead of new data types etc). You won't get away with this here!
The Game of Amazons.
A more sensible choice than trying to write a chess program - but still challenging. Like with many board games it can be solved in stages, where the first stage is to support a two-player game. Then if you have time you can try and build an AI. More online.
Tetris. A classic. But don't get too tied up in the GUI stuff.
Minesweeper. Another classic single-player game without any serious graphical needs. For more of a challenge you can try to write a solver.
Programming language projects.
Functional languages are ideal for implementing programming language tools such as compilers and interpreters. If you have some interest in this then here are labs which might form the basis for a project - here is one from a discontinued course:
A Bytecode Interpreter and Type Checker for a small stack-based byte code language.
This was a lab from a discontinued course in Programming Language Semantics. Only really suitable if you have seen operational semantics specifications before or are willing to learn (it is not too hard). Provides interesting challenges for testing.
You might also try implementing some other language - e.g. a functional language - (but there are similar labs in some other programming language courses at Chalmers).
- Conway's game of life. It's too simple and we have seen too many of them.
- Building a web server using some library. There are indeed some cool web server libraries for Haskell, but they don't make for a good project.