%TOC%
---++ 2012
---+++ Practical Advice
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 [[EducationPage][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 [[http://www.cs.uu.nl/wiki/pub/USCS2010/ComputerLab/Intro.pdf][an introductory tutorial]] and [[http://www.cs.uu.nl/wiki/pub/USCS2010/ComputerLab/Lists.pdf][and another one on lists]]. As a preparation for the second practical, use [[%ATTACHURL%/Trees.pdf][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 [[%ATTACHURL%/State.pdf][another one]] for a better understanding of monads. Here is the solution for the monad tutorial that has been presented during the last werkcollege: [[%ATTACHURL%/Tuple.hs][Tuple.hs]], [[%ATTACHURL%/StateDo.hs][StateDo.hs]], [[%ATTACHURL%/StateBind.hs][StateBind.hs]], [[%ATTACHURL%/StateTypeSyn.hs][StateTypeSyn.hs]], [[%ATTACHURL%/StateData.hs][StateData.hs]]. The code has not been tested. Here is also a simplistic parser implementation based on the state monad. A first attempt ([[%ATTACHURL%/ParserDet.hs][ParserDet.hs]]) and something that should work: [[%ATTACHURL%/ParserMaybe.hs][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 [[http://www.cs.uu.nl/docs/submit/][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 [[%ATTACHURL%/dobbelen.pdf][an assignment]] borrowed from an Open University course on functional programming. It has to be submitted before 2013. It is in Dutch. [[mailto:jan@rochel.info][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
[[%ATTACHURL%/Cartography.pdf][The third assignment]] revolves around graphs and parser combinators.
   * [[%ATTACHURL%/TooSimpleParseLib.hs][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 [[%ATTACHURL%/TooSimpleParseLib.hs][TooSimpleParseLib.hs]], some important functions like _many_ (= _pMany_) are from [[http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Applicative.html][Control.Applicative]].
   * If you're using a queue and want to have a complexity of _O(1)_, use the [[http://hackage.haskell.org/package/dequeue][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 [[mailto:jan@rochel.info][Jan]] or [[mailto:alex.elyasov@gmail.com][Alex]] or come by (room BBL-570 or BBL-565) anytime.

---+++ Practical 2
[[%ATTACHURL%/Chess.pdf][The second assignment]] is about [[http://en.wikipedia.org/wiki/Chess][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:
   * [[%ATTACHURL%/initial.chb][a chess board file]]
   * [[%ATTACHURL%/endgame1.chb][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:

<verbatim>
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)
</verbatim>

This utterly meaningless code can be also written as follows:

<verbatim>
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)
</verbatim>
   
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 [[%ATTACHURL%/RaceTrack.pdf][RaceTrack.pdf]]. With the assignment three supplementary files are provided:
   * [[%ATTACHURL%/muh.rtr][muh.rtr]] (race definition file), 
   * [[%ATTACHURL%/SVG.hs][SVG.hs]] (support for SVG rendering), 
   * [[%ATTACHURL%/Parser.hs][Parser.hs]].

---++++ Notes
   * You can use the [[https://addons.mozilla.org/en-US/firefox/addon/auto-reload/][auto-reload plugin]] for Firefox to have the SVG re-rendered automatically after each move. For Chrome there is the [[https://chrome.google.com/webstore/detail/oilipfekkmncanaajkapbpancpelijih][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.