Lab 4A [Project proposals only - if you do the standard lab you should not submit 4A]
- Due 4 Dec 2023 by 23:59
- Points 0
Lab 4 will be essentially the same as last year. There are two options, a project, or the standard lab. You need to decide by week 6 which one you will do.
Here is a short video introducing Lab 4 Links to an external site. (2022)
Project If you want to do your own project you need to submit short proposal for your lab 4: latest on Monday in Week 6 in the Fire system (marked as 4A). You submit your project (4B) on Wednesday of week 7, and it will be graded at a short presentation meeting. [2023: we will do grading on Friday 15 December via zoom]
Standard Lab If you take the "standard lab" then you should not submit 4A at all - we will assume that you will do the standard lab in that case. You Submit your complete lab on Wednesday of week 7 (4B) and it is graded as for all the other labs.
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".
The description is split into several parts but you must submit the whole lab in one go as submission 4B. Most students who choose this lab in 2015 (when we did a small survey) were happy with their choice.
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:
-
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.
-
GUI libraries are often difficult to install (they are very platform-specific) and usually do not support a functional programming style. We suggest that you minimise this. Nevertheless, here are some suggestions:
-
Use threepenny-gui Links to an external site.. threepenny-gui uses a web browser for the user interface, so it is a fairly small and portable library. See the introduction to Part II of the Standard Lab for some useful info on threepenny-gui.
-
Use code.world/haskell Links to an external site.. This allows you to create and run graphics, animation and interactive games online. You can also develop and run your programs locally by installing codeworld-api Links to an external site., but this library has a lot of dependencies, so it may take some time to install it.
-
Other possibilities include gloss Links to an external site., gloss-game Links to an external site., HGL Links to an external site..
-
If you like cool vector graphics, you might find the diagrams Links to an external site. library interesting (see the tutorial Links to an external site. and the gallery Links to an external site., which has source code)
-
-
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 Links to an external site. is a helpful bunch.
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.
Presentation
Projects will be presented over zoom with a 5 minute oral presentation 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.
Important deadlines
- Submit short proposal: latest on Monday in Week 6 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.
If you do the standard lab it is graded as per the other labs. If you do your own project you will be mailed a link to a sign-up page for your presentation in Week 7.
- 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 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 9-men-morris game. Many small games make for nice mini projects. One example is the 9-men-morris Links to an external site. game. (You can play online Links to an external site.).
-
The Game of Amazons Links to an external site.. 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 Links to an external site..
-
Othello/Reversi. Ditto.
-
Tetris. A classic. But don't get too tied up in the GUI stuff. Note that you should not base your solution on any existing Haskell version of the game.
-
[Removed - seen it too often] 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 Download 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).
-
Non-recommended projects
- 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.
- Games with very many rules - the problem here is that project can end up wide but shallow. An example is Chess, which can and has made for a good project, but there really are a lot of rules to take care of, so you need to invest quite a lot of extra time to do something interesting.