Programming is not something you learn from a book. It is important that you master the theoretical knowledge, but also that you learn to write code yourself. Therefore, this course requires you to hand in three practical exercises which will be marked. You can work on them alone or together with a partner, but remember to make this explicit when handing in. Together with the marks for the written exam these will form the basis for your final mark.

Be aware that the time you spend in the "werkcolleges" is not nearly sufficient to complete the practicals. The werkcolleges are rather intended to give you an opportunity to get help with the theoretical exercises from the lecture and to ask about problems that you encountered working on the practicals. Also, please bear in mind that even though the theoretical exercises do not contribute to your marks directly, they are essential for passing the written exam. Do not neglect them! Also make sure that you can do these exercises without the assistance of a computer, since at the exam you will not have access to a computer either. Often the solution looks simple, once it has been presented to you. Working on the exercise sitting behind an empty piece of paper ua and ub are 0 then the two lines are cr is something entirely different. All in all, you should assume that this course demands no less effort from you as it is worth in ECTS points (7.5), which equates to about 210 hours of work over about 8 weeks. This equates to about 26.5 hours per week! http://www.cs.uu.nl/wiki/bin/view/FP/EducationPage At the werkcollege two students will share one computer, but you should try to do the exercises without assistance. Both partners can profit of working in a team, but make sure that not the same person is operating the the keyboard all the time. If you have a better grasp on a subject than your partner then try to explain! This is in general a very good way to strengthen your own understanding. Of course you are free to bring your own laptop.

Introductory Practicals (not to be handed in)

Before you approach the first practical we ask you to start at the first session to work through an introductory tutorial and and another one on lists. As a preparation for the second practical, use this tutorial on trees to make yourself familiar with data types. These exercises do not have to be handed in. Based on the trees tutorial, here is another one for a better understanding of monads. Here is the solution for the monad tutorial that has been presented during the last werkcollege: Tuple.hs, StateDo.hs, StateBind.hs, StateTypeSyn.hs, StateData.hs. The code has not been tested. Here is also a simplistic parser implementation based on the state monad. A first attempt (ParserDet.hs) and something that should work: ParserMaybe.hs. Please note that I'm not suggesting that a parser should be implemented that way. This code is rather intended to get a basic understanding about parsers and (more importantly) monads.

Submission

Use the Submit system to hand in your solutions. Remember to mention if you have done any bonuses.

Practical 4

The fourth practical is yet again about a little game. It consists of an assignment borrowed from an Open University course on functional programming. It has to be submitted before 2013. It is in Dutch. Let us know if this is a problem for you. A translation will then be added within a day.

Notes

There will be no additional exercise

Practical 3

The third assignment revolves around graphs and parser combinators.

TooSimpleParseLib.hs: simplistic parser combinator library as introduced in the lecture notes
People seem to be unsure about the exact features that are expected in the first exercise. Essentially the exercise is about getting comfortable with the most common parser combinators (which might be relevant for the exam). Therefore you try to show exactly that. Try to get a working parser that involves choices and repetition, then focus on the graph section. Add more versatility to the language once you think that the rest is finished.
Remember that not all combinators come from TooSimpleParseLib.hs, some important functions like many (= pMany) are from Control.Applicative.
If you're using a queue and want to have a complexity of O(1), use the Dequeue data-type instead of a list.

Notes

The assignment does not explicitely ask for a main function, so it is not a requirement. You might still want to supply at least a minimal one in order to help the graders.
Note that part 2 of the practical constitutes a generic purpose library. This should reflect in your programming and module organisation.
In order to optimise your parser, consider using the <<|> operator from the exam.
The deadline has been fixed to one week after the exam. You have to submit before Nov 14.
The first version of the practical was silly and overloaded. Apologies for the late and radical changes to the assignment, Hopefully no-one has been affected in a negative way. The connection between the parsing and the graph problem is a bit contrived, but surely you can live with that.
As usual you are free to ask any questions by e-mail either to Jan or Alex or come by (room BBL-570 or BBL-565) anytime.

Practical 2

The second assignment is about Chess and revolves around data-structures and classes. You are asked to implement a simplified version of the game and a algorithm to determine wether a situation has a winning strategy for one of the players within the next n rounds. Supplementary files:

a chess board file
a simple endgame situation you can use as a test for your lookahead

Notes

Important: Before handing in please make explicit where in your code the individual exercises are implemented, otherwise grading becomes very difficult. Thank you.
You may as a simplification of the chess rules, define hasLost without a one-step lookahead, i.e.: a player has lost the game if his king has been beaten.
The lookahead does not need to be efficient for more than a few steps but should be implemented (and functional) for any given number of steps. But try to avoid unnecessary complexity as a result of programming style.
The Rule data-type should actually be called Rules.
If you are short on time try to focus on showing us that you have understood the principles of functional programming and are capable of applying them in solving the problem, rather than debugging every little corner case of the game. At least avoid introducing chaos into your code due to last minute debugging.
In this practical you have much more freedom for choosing names of function, modules, types, etc, and their definition. This doesn't make things easier for you since you need to ensure that the graders are able to understand the purpose of what you define. Try to make things extra clear. Remember, that the best documentation is within the code itself. The fewer comments you require to make your code readable the higher the grade is that you can expect. (Of course comments can still be helpful.)
The laws for some class are not to appear as methods of the class but as properties of its methods.
A small source of confusion might be the fact that you are asked to declare an instance of Parse before you are asked to define the Parse class. This is a mistake in the exercise.
In the last practical there were submissions which used very long lines. The record was 534 characters! This is not going to be a discussion on maximum line length but a hint how you can avoid wasting space and mechanical editing work by using more intelligent indentation. When you want to indent code with respect to some language element like let, where, or anything else you do not have to position that code further right than that language element but simply have a higher indentation than the corresponding line. Consider for example:

f x y | x < y = if x > 0 then x
                         else y
      | y > x = w * z 1 2 3 4 5 where w = case x of 0 -> 1
                                                    1 -> 0
                                      z a b c d e = very long line of code
                                                        continued here
                            
m x y = do a <- b x
           c <- c a
           return (a + c)

This utterly meaningless code can be also written as follows:

f x y
    | x < y = if x > 0
        then x
        else y
    | y > x = w * z 1 2 3 4 5 where
        w = case x of
            0 -> 1
            1 -> 0
        z a b c d e = very long line of code
             continued here

m x y = do
    a <- b x
    c <- c a
    return (a + c)

The real difference of course shows only for more verbose code than the one shown here. Note how in the second version the indentation is insensitive to the length of lines. In the first version you would need to change the indentation of 5 lines when renaming f to, say f1.

Note that this might be considered a question of personal preference, so please regard this merely as as a hint on how you can do things differently.

Practical 1

The first practical is described in RaceTrack.pdf. With the assignment three supplementary files are provided:

muh.rtr (race definition file),
SVG.hs (support for SVG rendering),
Parser.hs.

Notes

You can use the auto-reload plugin for Firefox to have the SVG re-rendered automatically after each move. For Chrome there is the Auto Refresh Plus plugin.
The line intersection algorithm described on the website mentioned in the assignment is not entirely correct. At the very bottom of the page it misses the case where both segments lie on the same line, which requires another test for whether the line segments overlap or not. A correct implementation of this test will be considered a bonus. Bonuses allow you to gather additional points. Points that surpass the maximum of ten carry over to the next practical.
It has been mentioned that the moveValid function is not necessary for implementing the game. This is true, but you are still asked to implement the function without necessarily using it anywhere.
To test your program in ghci you can supply command-line arguments to the main function by typing :main args which (just as main) will run the main function but setting the command-line arguments before.