CS410 Practicals

This directory is a darcs repository of the source files used for CS410 practicals. Each practical consists of an unfinished Haskell program which the students should complete. The seven practicals are attempted through the course of semester 1 and carry 50% of the marks for the class, divided equally.

The remaining 50% of the marks for the class are awarded for a small project. to be undertaken in the five weeks after the Easter break (the usual time for the remainder of teaching, revision and exams). This project is a synthesis of all the materials from the class and seeks to deploy materials from practicals 1 to 7 in one application: an editing environment for the programming language FOUL.

Practicals 1 to 7

• Prac1.hs, being the implementation of the key logic for a text editor, linking with ANSIEscapes.hs, Block.hs, Overlay.hs and Main.hs A guide to the editor implementation, with tips for modification, is available.
• Prac2.hs, being an exercise in writing programs which use and/or expose bugs in my naive interpreter for the First Order Untyped Language, FOUL.hs
• Prac3.hs, being an attempt to make the FOUL interpreter safer by trapping errors with "Maybe"
• Prac4.hs, being the development of a Parser for FOUL
• Prac5.hs, being an exercise in programming in free monads
• Prac6.hs, being an exploration of "polynomial" functors built in kit form
• Prac7.hs, being a datatype generic development of first order unification

Final Project

The final project for CS410 is to develop an "integrated development environment" for programming in FOUL. This is worth 50% of the marks for the class, and it is intended to reuse in earnest materials developed in the earlier practicals.

The deliverables are

• a directory of source code for your IDE: this should build on a standard lab machine; if you really want to use a different environment, you need to negotiate some means by which I can build and run it;
• sufficient user documentation to allow the assessment of its functionality (undocumented functionality is unlikely to receive credit, as it will not be found);
• example files which demonstrate the functionality (which might include error-detecting functionality, as well as code which positively works).

The official deadline is midnight on Friday 17 May. In practice, submissions received before 9am on Monday 20 May will be accepted.

There was a lecture (as notified via myplace) at 2pm on Tuesday 16 April in LT209. There will be another such lecture at 2pm on Tuesday 23 April in LT209. In addition, I will be available for "office hours" between 10am and 2pm on Thursdays in weeks 11-13 and subsequently by appointment. Sign up on my door (LT1317) for 15 minute slots. If groups of you have similar issues, it makes perfect sense to sign up in groups (for longer slots pro rata, if you like). Please also do use the myplace forum to raise issues, and in particular to suggest topics which need attention in lectures.

25/50 marks are for delivering a basic environment which allows the editing of a FOUL source file. On exit, the file should be parsed, and if the parse is successful, the "main function" should be executed and its result displayed. The other 25/50 are for "value added", giving considerable scope for individual initiative. Possibilities include

• extending the editor, e.g. to support saving and loading of files, or clipboard functionality
• making the editor interact with the parser to show syntax errors
• extending the FOUL language with side-effecting operations, perhaps interpreted using a free monad
• shifting from untyped FOUL to a typed language; an example type checker TC.hs based on solutions to practicals 6 and 7 has been provided
• making the editor interact with the typechecker to show type errors
• making the editor interact with the type system to assist in program construction

The marking scheme is in accordance with the standard university scale, hence a comprehensive implementation of some straightforward added value will score upwards of 30/50, whilst a demonstration of excellence by cracking a challenging problem will secure a mark of at least 35/50. The emphasis, as with projects, is more on the functionality delivered than on code. Style can turn a good mark into a great mark, but will never counteract the value of getting something to work.

Sign-up slots are a good opportunity to discuss your plans, and how difficult/rewarding a given piece of functionality is likely to be.