Practical Assignments

Below are listed the practical assignments of this year. If you did the course before contact the lecturer via MS Teams about what you should do and should not do.

All assignments should be performed in teams of two. You are free to discuss ideas on design and implementation (because the necessary explaining helps you understand), but you may never share between teams any code or documentation, or even letting them read it from a screen. It is the responsibility of both team members to ensure that both members participate equally. Also, note that understanding of much of the material in this course comes mostly from implementing it.

In my experience students underestimate how hard practicals are. It usually works best to at least visit the practical slots and make sure you are on the right way.

Name	Deadline	Type	Specification
Monotone frameworks (30% of final grade)	Wednesday 1st of June 2022, 23:59	Lab, in pairs, individual is allowed, also see below	mf.pdf mf-base.zip
Type and effect systems (30% of final grade)	Fri 1st of July, 2022, 23:59	Lab, in pairs, individual is allowed	tande.pdf tande-base.zip

For the Monotone Frameworks assignment it is typically possible to do something more adventurous, like type analysis for Python or PHP. However, the risks are all yours. It is mandatory to talk to the lecturer before you attempt such a project. The maximum number of participants for a project such as this is three (instead of the usual two for the standard assignment). Note that you must use monotone frameworks to do this, so in essence you are implementing the same techniques, but in a more complicated context. Also, another way to make this assignment more challenging is by doing many extras as explained in the project description.

What to hand in?

For the practical assignments, we expect at least the following to be submitted:

• The source code of your implementations which must include any UUAG sources, Haskell sources not generated by the UUAG system. It is your responsibility to ensure that the code is well-structured, well-documented etc.
• Documentation in pdf format that describes the design of your solution, and any explanation and contents required by the particular assignment. This could be, for example, type rules for a type and effect system, or transfer functions for a monotone framework analysis.
• A README file containing the following important pieces of information:
  • who are the submmitters (name and student number)
  • what functionality (including any extras!) you have implemented,
  • where the starting point of the design documentation is to be found
• For most, if not all, assignments we expect you to come up with a collection of examples, and we expect you to go through a few of these in your pdf documentation to show that your implementation works as expected.
• The code should work with stack run. Please don’t change the build system from the template.