COMP1100/1130 Assignment 1, Semester 1 2023
In this assignment, you will build a Haskell program that uses the CodeWorld API to draw colourful shapes on the screen.
This assignment is worth 10% of your final grade.
Part A: Thursday March 23, 2023, at 11:00pm Canberra time sharp
Part B: Sunday April 9, 2023, at 11:00pm Canberra time sharp
Please note that Daylight Savings ends on Sunday 2 April. Note: Late submissions will not be marked unless you have an approved extension.
Indicative marks and feedback for Part A will be returned in week 6.
If you have finished the Week 3 lab, you should be able to complete Part A.
If you have finished the Week 4 lab, you should be able to complete the majority of the assignment. Some parts require recursion over lists, which is covered in the Week 5 lab.
Overview of Tasks
|COMP1100 Marks||COMP1130 Marks|
|Task 1: Helper Functions||20 marks||10 marks|
|Task 2: Rendering Shapes||35 Marks||30 Marks|
|Task 3: Handling Events||30 Marks||25 Marks|
|1130 Extensions||-||30 Marks|
|Technical Report||15 marks||25 marks|
|Total||100 marks||120 marks|
Part A of the assignment requires you to complete Task 1.
Part B of the assignment requires you to complete all assigned tasks.
As you complete each task (or even each function within a task), once your code compiles without errors, you should commit and push your work with a sensible commit message.
The purpose of Part A is to give you an opportunity to collect feedback on your code and your progress in the course, and for us to give you an indicative mark for your work so far. This will be returned to you before the census date. Part A will be re-marked alongside your Part B submission, giving you a final mark for the assignment.
Fork the assignment repository and create a project for it in VSCodium, following the same steps as in [Lab 2](/courses/comp1100/labs/02/. The assignment repository is at https://gitlab.cecs.anu.edu.au/comp1100/2023s1/2023s1studentfiles/Assignment1.
Add our version of the repository as a remote called
upstream. This allows us to provide additional fixes in the unlikely case that they are required. You do this by doing the following:
- Go to the command palette in VSCode (or VSCodium) by pressing
Ctrl + Shift + p
- Click Git: Add Remote
- Put the following URL as the remote url:
upstreaminto the box for the remote name
- Go to the command palette in VSCode (or VSCodium) by pressing
Overview of the Repository
Most of your code will be written to Haskell files in the
directory. We are using the
pattern to structure this assignment. Each file is called a module,
and we use modules to group related code together and separate
The model is a data type that describes the state of the running
program. The program will move to new states (new values of type
Model) in response to user actions, as defined by the
The view turns the model into something that can be shown on the
screen; in this project, that is the CodeWorld
The controller considers user input (and other events), along with the current model, and uses that to decide what the new model should be.
tests/ShapesTest.hscontains some unit tests - simple checks that verify small parts of your program are working correctly. You are not required to write tests for this assignment, but you might find it useful to do so.
tests/Testing.hsis a small testing library used by
tests/ShapesTest.hs. You are not required to understand it for this assignment.
app/Main.hsties your functions together into the final program that runs. You are not required to understand it.
comp1100-assignment1.cabaltells the cabal build tool how to build your assignment. You are not required to understand this file, and we will discuss how to use cabal below.
Setup.hstells cabal that this is a normal package with no unusual build steps. Some complex packages (that we won’t see in this course) need to put more complex code here. You are not required to understand it.
Overview of Cabal
cabal is the build tool for Haskell programs and libraries. It
provides several useful commands:
cabal v2-build: Compile your assignment. Note that because of some code provided for you by us you will see some warnings about unused variables; you will fix these warnings during Task B, so may ignore them for Task A.
cabal v2-run shapes: Build your assignment (if necessary), and run the
shapesprogram. Note that you will need to enter
Ctrl-Cin your terminal to exit the program.
cabal v2-repl comp1100-assignment1: Run the GHCi interpreter over your project. This gives you the same ghci environment you use in labs, but with the assignment code loaded. (Aside: REPL is the name for interactive sessions like GHCi - it stands for read-eval-print loop. Many modern languages have REPLs.)
cabal v2-test: Build and run the tests. Tests will abort on the first failure, or the first call to a function that is still
You should execute these cabal commands in the top-level directory of your
~/comp1100/assignments/Assignment1 (i.e., the directory you are in when you
launch the VSCodium Terminal for your project).
Overview of the Program
You use a web browser to interact with the
shapes program that you
cabal v2-run shapes. Once you have completed the
assignment, it will respond to the following actions:
||Clear the canvas.|
||Display a sample image.|
||Change colour (of shape to draw).|
||Change tool (type of shape to draw).|
||Remove the last added shape.|
||When drawing a polygon, finish drawing the polygon, adding it to the canvas. Otherwise, nothing.|
||Adjust the x-axis tilt (x-tilt) of the parallelogram by
||Adjust the x-axis tilt (x-tilt of the parallelogram by
||Adjust the y-axis tilt (y-tilt) of the parallelogram by
||Adjust the y-tilt of the parallelogram by
||Print the current
|Click-drag-release (mouse)||Used to draw various shapes.|
|Click (mouse)||Used to draw various shapes.|
Task 1: Helper Functions (COMP1100: 20 marks, COMP1130: 10 marks)
The easiest way to solve a large problem is often to break it apart
into smaller, easier problems. Programming is the same. In this task
you will write some helper functions that will make future tasks
easier. You can test your implementations by running
The functions you need to write for this task are:
src/View.hs. This function should return instructions for the user on how to use each
Tool, according to the following table:
Note: At the time this assignment is released, the course will have only
briefly covered lists. You do not need to manipulate lists to write
toolToLabel; you can use a blank pattern (
_) to ignore them.
src/Controller.hs. This function should return the next colour in our set of
src/Controller.hs. This function implements tool-switching, but should not change
Toolif the user is halfway through an operation:
If the tool is not holding a point (that is, a
PolyToolholding the empty list
, or a
Parallelogramtool whose first argument is
Nothing, or any other tool holding
Nothing), select the next tool in the following sequence:
Line. Note that the x-tilt and y-tilt of the parallelogram should be initialised at
If there is a
Pointstored in the given tool (because it is holding a
Justvalue or the list in
PolyToolis non-empty), return the argument unchanged.
If this is unclear, study the
Note: At the time this assignment is released, the course will have
only briefly covered lists. You can write the
PolyTool case for
nextTool without using list recursion. Use
 to match an empty
list. In a subsequent case, give the entire list a name like
to match any nonempty list (or find a way to use the
Part A ends here.
Submitting Part A
Your submission for Part A should include implementations of
compile without warnings and pass the tests run by
You are welcome to continue working on Part B of your assignment
and committing and pushing changes, so long as your code continues
to compile without errors and the tests continue to pass.
Part B begins…
Task 2: Rendering Shapes (COMP1100: 35 marks, COMP1130: 30 marks)
modelToPicture converts your
Model type into a
Picture, so that it can be displayed on the screen. It
currently does not work, because
undefined. In this task you will fill in that missing piece,
building up a function to convert the
[ShapeColour] from your
Model into a
Picture. You can test these functions individually by
cabal v2-repl comp1100-assignment1, using
drawingOf to show
small pictures on the screen.
If you wanted to test functions from
View.hs e.g. if your prompt shows
you can use ghci commands to load the specific module i.e.
which should change the ghci prompt accordingly.
You can also test everything as a whole
by launching the program with
cabal v2-run shapes and pressing the
key to show the sample image. The functions you need to write for
this task are all in
colourNameToColour: This function turns your
ColourNametype from the model into a CodeWorld
Colour. You should check the CodeWorld documentation for information on colours. There are three colours in the list that you will need to construct yourself. Indigo has RGB values (75, 0, 130) and Violet has HSL values of (300, 0.25, 0.25). Sludge is the mixing of all other non-sludge colours, excluding white and black (note: This will require you to check the codeworld documentation, rather than rely on what has already been covered in labs).
shapeToPicture: This function turns your
Shapetype into a CodeWorld
Picture. You will need to consider the constructors for
Shapeindividually, and work out the best way to turn each one into a
Picture. Here are some hints to help you along:
CodeWorld has no function to draw a single line segment. It does have a function to draw a line made of multiple segments -
polyline. It also has no function for the triangles or parallelograms of this assignment, but it does have functions that can draw these shapes.
Polygons, Circles, Triangles and Parallelograms should be drawn as solid (filled)
Many of CodeWorld’s functions draw individual shapes centred on the origin -
(0, 0). You will need to figure out how to slide (translate) the generated
Pictureso it shows up where it is supposed to go. Drawing diagrams will help. The
absfunction might also help - it computes the absolute value of its argument (i.e.,
abs x == xif
x > 0, and
abs x == - xotherwise).
- (Isosceles right) triangles should be defined by clicking and dragging a line
representing the hypotenuse of the triangle. The other two sides should have
equal length and are positioned as follows:
- If the hypotenuse is drawn from the top right to the bottom left then the rest of the triangle is formed above the hypotenuse.
- If the hypotenuse is drawn from the bottom left to the top right then the rest of the triangle is formed below the hypotenuse.
- If the hypotenuse is drawn from the bottom right to the top left then the rest of the triangle is formed above the hypotenuse.
- if the hypotenuse is drawn from the top left to the bottom right then the rest of the triangle is formed below the hypotenuse.
- Otherwise, if the user-defined hypotenuse is perfectly vertical or horizontal, you should define reasonable behaviour that ensures that an isosceles right triangle is drawn with that hypotenuse.
- Our parallelograms are defined by clicking and dragging a line to draw the
diagonal of a square, then this square is
tilted along the x axis and along the y axis by the xtilt and ytilt values
- hint: the
atan2function (the two argument arc-tangent) in the Haskell prelude may be useful here.
Examples of a parallelograms with no x-tilt and no y-tilt.
An example of a parallelogram with a x-tilt of π/20.
An example of a parallelogram with a y-tilt of π/20.
An example of a parallelogram with a y-tilt of -π/20, and a positive x-tilt of π/20.
An example of a rotation of a parallelogram by giving it positive y-tilt and positive x-tilt both of π/20.
All parallelograms here were initial drawn with an approximately horizontal diagonal. The y-tilt and x-tilt are relative to the initial orientation of the parallelogram, or said another way all parallelograms start with an x-tilt and y-tilt of 0 regardless of how they are drawn.
- hint: the
colourShapeToPicture: This function should render the
Shapeand colour it using the Colour that corresponds to the given
colourShapesToPicture: This function should turn every
ShapeColourin a list into a single
Picture. You will need to recurse over the input list. If you have not yet completed Lab 5, you may want to work on other parts of the assignment and come back to this. In particular, we should draw older shapes first, and newer shapes last, so that newer shapes overlay older ones.
Here is the sample image for you to test your work against:
Your parallelograms make look slightly different to the test image depending on your implementation. Any implementation that matches the specification for the parallelograms above will have the opportunity to earn full marks, even if they differ from the text image.
Task 3: Handling Events (COMP1100: 30 marks, COMP1130: 25 marks)
It is now time to tackle
src/Controller.hs. CodeWorld calls this function whenever something
interesting happens (like a key press, a pointer press, or a
pointer release). This function is called with two arguments:
Eventthat just happened, and
- The current
Modelat the time the
handleEvent then returns a new
Model for the program to use moving
Let’s trace a simple interaction. If the user wants to draw a red line by clicking on the screen at coordinates \((1, 1)\) and releasing the mouse at coordinates \((2, 2)\). starting at a blank canvas, the state would transition as follows, starting with the initial model:
Model  (LineTool Nothing) Black
The user presses “C” to change the colour from black to red:
Model  (LineTool Nothing) Red
The user presses the mouse button at \((1, 1)\) changing the state to
Model  (LineTool (Just (1.0,1.0))) Red
The user releases the mouse button at \((2, 2)\) changing the state to
Model [(Line (1.0,1.0) (2.0,2.0),Red)] (LineTool Nothing) Red
Note that the
Tool and the
ColourName do not reset to the default values
after a shape has been drawn. However, the
Maybe Point inside the tool
should revert to
Task 3.1: Handling Mouse Input
CodeWorld provides a few different event constructors for mouse input,
but the ones we’re interested in here are
PointerPress for when the user
PointerRelease for when the user releases the mouse
PointerPress event arrives, you will need to store it in the
Tool. For everything except
PolyTool, you will store it
Maybe Point argument. For
PolyTool, you will add it to
the list of vertices.
PointerRelease event arrives, we can ignore it for
PolyTool, as we will be finishing polygons using
the spacebar in Task 3.2. For almost everything else, a
mean the end of a click-drag-release action, so you should construct the appropriate
shape and add it to the
[Shape] in the
Model. You should also
remove the starting point from the current
Tool, so that future
shapes draw properly too.
Once you have finished this task for normal input, you may also want to consider
how your program will behave on unexpected input. For example, what should your program
do if it receives two consecutive
PointerPress inputs without a
PointerRelease between them?
Task 3.2: Handling Key Presses
To handle keyboard input, CodeWorld provides a
KeyPress event. This
is already present in the assignment skeleton, because we have
implemented some keyboard functionality already. In the “Overview of
the Program” section, we listed the full set of keyboard commands that
your program will respond to. You need to implement the missing
functionality for these keys:
||Change colour (of shape to draw)|
||Change tool (type of shape to draw)|
||Remove the last added shape|
||Finish drawing a polygon, adding it to the canvas.|
||Increase/decrease the parallelogram x-tilt angle by π/20.|
|If the current tool is not the
||Increase/decrease the parallelogram y-tilt angle by π/20|
|If the current tool is not the
For the parallelogram. Pressing ← or → should adjust the tilt along the y axis left or right respectively, and pressing ↑ or ↓ should adjust the tilt along the x axis respectively.
Changing tool (but not drawing another shape) with ‘T’ and cycling back to
ParallelogramTool should let you adjust the x-tilt and y-tilt of the
most recently drawn parallelogram.
If you have made it this far, you should not need to write a lot of code to implement these. A few hints:
- Think back to Task 1.
Deletewith no shapes drawn should not crash the program.
- Nor should any other unexpected input. Try to test some ``unexpected’’ cases.
Task 4: 1130 Extensions (COMP1130 Only: 30 Marks)
COMP1100 students are welcome to attempt extensions so long as that does not inhibit the function of tasks 1-4, but will not gain marks for completing them.
COMP1130 students will need to complete two of the five extensions from the pool below. If you attempt more than two, you must indicate which two you wish to be marked. Otherwise, we will mark the the first extensions you have completed in the order they appear in this document.
If you change the behaviour of tool or colour switching, you may want to adjust the tests in `tests/ShapesTest.hs’ so they continue to pass. They must continue to compile without errors.
Note: Extension functionality must be executed through the codeworld API just like
the rest of the assignment. Interactions should be received through the
function, which you will need to modify. If you need to add arguments to the model, please
do so after the existing ones:
data Model = Model [ShapeColour] Tool ColourName YourArgument1 YourArgument2 ...
Task 4.1: A Rainbow Shape.
Add a new
Shape, and any additional changes to the underlying
are necessary to create a ‘rainbow’ shape. This shape should draw a rainbow by
drawing consecutive adjacent arcs in the colour order:
How the user draws this shape and how this multicoloured shape fits in with the
ShapeColour type is up to you, but must be clearly documented and
explained in your report.
Task 4.2: Preview
Preview shapes as the user draws them. If the user has started to draw a shape, then you should show the shape currently being drawn using a hollow (not solid) shape. Circles, Triangles, and Parallelograms should show a solid line for the diameter, hypotenuse, or diagonal current being dragged, along with a a hollow outline of the proposed shape if the user were to release at the current point. For Polygons, show a thick line between each point that has been added to the list so far, and preview the current point and a line back to the origin.
Task 4.3: Colour Picker
Add a tool allowing users to change the colour in use by clicking on part of the picture with that colour. For example, if they click inside a red circle the colour in use should change to (or remain at) red. There should be some sensible default behaviour if the user clicks on a part of the picture that is not drawn on. You may ignore non-convex polygons for this task; adding this functionality will not attract further marks, but is an interesting challenge!
Task 4.4: Freehand Drawing Tool
Add a free-hand drawing tool. When using this tool, moving the mouse with the button pressed should draw short lines or curves, as if a pen is being dragged across the screen. If the button is released, the program should stop drawing.
Task 4.5: Animation
Your model need not only react to user inputs; it can also react to time passing, which allows you to animate your pictures! You may choose which way(s) the shapes and/or colours in your pictures change over time, although the animation must be dynamic or depend on the picture in the model - a pre-defined repeating animation would not be sufficient. Users should be able to turn animations on and off. Please be mindful of the speed at which your pictures change, so that you do not create an unpleasantly fast strobe-like effect.
Technical Report (COMP1100: 15 marks, COMP1130 25 marks)
|Description||COMP1100 Mark||COMP1130 Mark|
|Documentation (what you did)||4||7|
|Reflection (why you did it)||4||7|
|Testing (how you tested)||4||7|
|Style (how the report presents)||3||4|
You should write a concise technical report explaining your design choices in implementing your program. The maximum word count is 1000 for COMP1100 students and 1500 for COMP1130 students. This is a limit, not a quota; concise presentation is a virtue.
Once again: These are not required word counts. They are the maximum number of words that your marker will read. If you can do it in fewer words without compromising the presentation, please do so.
Your report must be in PDF format, located at the root of your
assignment repository on GitLab and named
Report.pdf. Otherwise, it
may not be marked, or will be marked but with a penalty. You should
double-check on GitLab that this is typed correctly.
The report must have a title page with the following items:
- Your name
- Your laboratory time and tutor
- Your university ID
Content and Structure
Your audience is the tutors and lecturers, who are proficient at programming and understand most concepts. Therefore you should not, for example, waste words describing the syntax of Haskell or how recursion works. After reading your technical report, the reader should thoroughly understand what problem your program is trying to solve, the reasons behind major design choices in it, as well as how it was tested. Your report should give a broad overview of your program, but focus on the specifics of what you did and why.
Remember that the tutors have access to the above assignment specification, and if your report only contains details from it then you will only receive minimal marks. Below is an potential outline for the structure of your report and some things you might discuss in it.
If you wish to do so you can write an introduction. In it, give:
- A brief overview of your program:
- how it works; and
- what it is designed to do.
- If you have changed the way the controls work, perhaps for an extension, or added something that may make your program behave unexpectedly, then it would be worth making a note of it here.
This section is particularly relevant to more complicated programs.
Analysis of your Program
The purpose of this section is to describe your program to the reader, both in detail and at a high level.
Talk about what features your program actually has. We know what we asked for (the features in this document!), but what does your program actually let a user do? How does your program work as a whole?
How does it achieve this? Let us know how each individual function works and how they work together to solve particular design goals.
As an example, you might have used a number of helper functions to achieve a particular design goal of drawing right-angled isosceles triangles. If so, tell us what these functions are, what they do, and how they compose or otherwise work together to achieve this goal.
A successful report will demonstrate conceptional understanding of all relevant functions, and depicts a holistic view of program structure through discussion of what it is and hour it works.
Rationale and Reflection
The purpose of this section is to describe the design decisions you made while writing the program, to the reader.
Tell us the reasoning behind the choices you detailed above. Tell us the assumptions you made about user behaviour. Why did you solve the problems the way you did? Why did you write the functions you wrote? Did you make any other assumptions?
“I implemented the
checkFirst helper function after
reading this blog post (citing the post as a reference),
claiming that users of quadrant based drawing programs virtually always draw
their first shape in the top-right quadrant. Deciding to use this as my base
assumption for user-behaviour, I decided to save on
quadrant-dependent calculation of trigonometric ratios by always assuming the
first shape is drawn in this quadrant. This in turn meant I needed a function
to check if a shape was the first one drawn.”
This is a critical reflection not a personal one. You’re explaining the justification and reasoning behind the choices you made.
A successful report will give a thorough explanation of the process followed to reach a final design, including relevant reasoning and assumptions / influences.
This purpose of this section is to give the reader confidence that your program has been thoroughly tested.
Tell us how you tested the program as a whole to ensure correctness. Tell us in detail how you tested individual functions to ensure correctness.
“I drew all possible directions of the hypotenuse on the coordinate plane, to ensure that the isosceles, right-angled triangle was correctly drawing up, down, left, and right.”
“I wrote a unit testing helper function
validateTriangles :: Shape -> Bool which
True if, and only if the angles sum up to 360 degrees,
for every triangle on the coordinate plane.”
A successful report will demonstrate evidence of a process that checked most, if not all, of the relevant parts of the program through testing. Such a report would combine this with some discussion of why these testing results prove or justify program correctness.
A successful report should have excellent structure, writing style, and formatting. Write professionally, use diagrams where appropriate but not otherwise, ensure your report has correct grammar and spelling.
This is a list of suggestions, not requirements. You should only discuss items from this list if you have something interesting to write.
Things to avoid in a technical report
Line by line explanations of large portions of code. (If you want to include a specific line of code, be sure to format as described in the “Format” section below.)
Pictures of code or your IDE.
Content that is not your own, unless cited.
Grammatical errors or misspellings. Proof-read it before submission.
Informal language - a technical report is a professional document, and as such should avoid things such as:
- Unnecessary abbreviations (atm, wrt, ps, and so on), emojis, and emoticons; and
- Stories / recounts of events not relevant to the development of the program.
Irrelevant diagrams, graphs, and charts. Unnecessary elements will distract from the important content. Keep it succinct and focused.
If you need additional help with report writing, ANU Academic Skills have resources to help.
You are not required to follow any specific style guide (such as APA or Harvard). However, here are some tips which will make your report more pleasant to read, and make more sense to someone with a computer science background.
- Colours should be kept minimal. If you need to use colour, make sure it is absolutely necessary.
- If you are using graphics, make sure they are vector graphics (that stay sharp even as the reader zooms in on them).
- Any code, including type/function/module names or file names, that appears in your document should have a mono-spaced font (such as Consolas, Courier New, Lucida Console, or Monaco)
- Other text should be set in serif fonts (popular choices are Times, Palatino, Sabon, Minion, or Caslon).
- When available, automatic ligatures should be activated.
- Do not use underscore to highlight your text.
- Text should be at least 1.5 spaced.
Do not post your code publicly, either on Ed or via other forums. Posts on Ed trigger emails to all students, so if by mistake you post your code publicly, others will have access to your code and you may be held responsible for plagiarism.
Once again, and we cannot stress this enough: do not post your code publicly . If you need help with your code, post it privately to the instructors.
When brainstorming with your friends, do not share code. There might be pressure from your friends, but this is for both your and their benefit. Anything that smells of plagiarism will be investigated and there may be serious consequences.
Sharing concepts and sketches is perfectly fine, but sharing should stop before you risk handing in suspiciously similar solutions.
The use of generative AI tools (i.e ChatGPT) is not permitted in this course.
Course staff will not look at assignment code unless it is posted privately in Ed, or shared in a drop-in consultation.
Course staff will typically give assistance by asking questions, directing you to relevant exercises from the labs, or definitions and examples from the lectures.
Before the assignment is due, course staff will not give individual tips on writing functions for the assignment or how your code can be improved. We will help you get unstuck by asking questions and pointing you to relevant lecture and lab material. You will receive feedback on you work when marks are released.
Once you have finished your assignment, and preferably 24 hours prior to the deadline, you should make sure that:
- You have fully read and understand the entire assignment specification.
- Your work has been pushed to GitLab. You should check this using your browser by viewing your repository at https://gitlab.cecs.anu.edu.au/uXXXXXXX/assignment1 , where XXXXXXX is replaced by your university ID. It is your responsibility to confirm that your submission, including for your report, has been successful.
- Your program compiles and runs, including the
cabal v2-testtest suite.
- Your program works on the lab machines - if the program does not work on the lab machines, it might fail tests used by the instructors.
- You have proof-read and spell-checked your report.
- The report is in PDF format, located at the root of your project on
GitLab and named
Report.pdf. That capital
Ris important - Linux uses a case-sensitive file system. Otherwise, it may not be marked. Check this on Gitlab as the full filename may not always appear in your document.