Assignment P2

Assignment P2#

This assignment is restricted to using the Functional Java libraries. In everything you do, you must follow the Design Recipe. To see roughly how this assignment will be marked, check out the Skeleton Rubric.

You really really need to stick to the restrictions of Functional Java. Don’t just write Java code simply because you already know Java. The penalties in the rubric for doing so are quite harsh.

Formalities#

This assignment is submitted via GitLab.

Access to Your Repository#

In order for us to be able to collect and mark it, you need to satisfy the following conditions:

• Your repository’s name must be comp6710-2025s1-p2 (exactly), placed directly in your user namespace (the default). That is, if your uid is u1234567, the address of your GitLab project should read as https://gitlab.cecs.anu.edu.au/u1234567/comp6710-2025s1-p2.
• Your repository must have our marker bot (comp1110-2025-s1-marker) added as a Maintainer.

You can achieve both these points by creating your project through forking our template repository and not changing the name, or by just using the correct name when creating the project and then manually adding the bot.

Notebooks and Push Requirement#

You need to keep a notebook file as explained on the Git and Notebooks page. You need to commit and push the current state of your files:

• at the end of every session where you work on the assignment
• at least once per hour (our checks implement this that no two pushes during sessions recorded in the notebook are more than 70 minutes apart).
• at least once per major part of the assignment (i.e. for this assignment, at least four times). You are absolutely free to commit and/or push more often than that.

You need to write informative commit messages, and informative notes for each session in your notebook, which describe what it is that you did for this particular commit or session, respectively.

Statement of Originality#

Your submission (and therefore your git repository) needs to include a signed statement of originality. This must be a text file named soo.txt. That file must contain the following text, with the placeholders [your name here] and [your UID here] replaced with your name and UID, respectively:

I declare that this work upholds the principles of academic
integrity, as defined in the University Academic Misconduct
Rule; is entirely my own work; is produced for the purposes
of this assessment task and has not been submitted for
assessment in any other context, except where authorised in
writing by the course convener; gives appropriate
acknowledgement of the ideas, scholarship and intellectual
property of others insofar as these have been used; in no part
involves copying, cheating, collusion, fabrication, plagiarism
or recycling.

I declare that I have not used any form of generative AI in
preparing this work.

I declare that I have the rights to use and submit any assets
included in this work.

[your name here]
[your UID here]

Files Summary#

Your repository must be accessible to us and must contain the following files in its root directory:

• notebook.yml - your Notebook
• soo.txt - your signed Statement of Originality
• Permutations.java - containing your work for parts 1 and 4
• AlarmClock.java - containing your work for parts 2 and 3

Code-Walk Registration#

Our goal is to eventually move to CWAC for Code-Walk Registration and Schedule Preferences. As of the release of this assignment, that system is not yet ready. In the meantime, you can use this form to indicate that you want to be scheduled for a code walk for this assignment. Please use CWAC to register for a code walk. You can also use it to give time preferences for scheduling your code walk.

The deadline for registering to participate in code walks is Friday, 14 March 2025, 18:00. You need to do this in order for your assignment submission to get marked!

Tasks#

Part 1#

In a file called Permutations.java

Let’s get some practice with lists! For this part, you must not use higher-order list functions from the standard library Design the following functions:

/**
 * Determines if two lists are permutations of each other.
 * Two lists a permutations of each other if they contain the
 * same elements, but possibly in a different order. For example, 
 * [2, 1, 3] is a permutation of [3, 1, 2], and vice versa.
 */
boolean isPermutation(ConsList<Integer> list1,
                      ConsList<Integer> list2)
// make sure to test this function with some large positive (>10,000) 
// and negative (<-10,000) numbers. You have been warned!

/**
 * Compares two equal-length lists lexicographically, and returns an
 * integer following the standard scheme for comparison functions (a
 * negative integer if the first argument is less than the second, 0
 * if they are equal, a positive integer otherwise). Lexicographic
 * comparisons go from the first to the last element, and are either
 * decided by the first element that is not equal between the two
 * lists, in which case the list with the "lesser" element is the 
 * "lesser" list, or end at equality of they both only compare equal
 * elements.
 */
int compareLists(ConsList<Integer> list1,
                 ConsList<Integer> list2)
// make sure to test this function with some large positive (>10,000) 
// and negative (<-10,000) numbers. You have been warned!

/**
 * Inserts the given element at the given index into the given list,
 * (i.e. the element's index in the returned list corresponds to the
 * given argument). Indices start at 0 for the first element, and
 * end at Length(list)-1 for the last element.
 */
ConsList<Integer> insert(int element, int index,
                         ConsList<Integer> list)

Follow the Design Recipe!

Part 2#

In a file called AlarmClock.java

For this part, you may use higher-order list functions from the standard library wherever applicable

For this part, we will model alarm clocks. Our alarm clocks work on a certain cycle, which may be different for each clock. They advance in ticks that have numbers, starting at 0 and going up to (but not including) their upper cycle limit. If they would go beyond their upper cycle limit, they reset their tick number to 0, and start the cycle again. At any point, a user can register one of two kinds of alarms for particular tick times:

• Recurring alarms: these alarms will be triggered whenever the clock hits a particular tick time
• One-time alarms: these alarms will be triggered the next time the clock hits a particular tick time, but not anymore after that

We model alarms with functions that take an integer argument (the current tick time - should be equal to the time for which they were registered) and produce a String. The tick function will include this String in its return value whenever an alarm is triggered. At each tick, only one alarm function can run, so when a new alarm is registered, it may override an old one. Design the following functions:

/**
 * Registers a recurring alarm that is run every time the
 * clock hits the given tick time.
 * Overrides any alarms that may have already been registered
 * for that time.
 */
[C] registerRecurringAlarm(Function<Integer, String> alarm, 
                           int time,
                           [C] clock)

/**
 * Registers a one-time alarm, which will be triggered once when
 * the clock hits its set time, but not anymore afterwards.
 * Overrides any alarms that may have already been registered
 * for that time.
 */
[C] registerOneTimeAlarm(Function<Integer, String> alarm,
                         int time,
                         [C] clock)

/**
 * Advances the tick counter by one, and if that tick counter equals
 * an alarm's set time, the alarm is triggered with the current tick 
 * counter as an argument, and the result of calling the alarm is
 * returned together with the new state of the clock.
 * If no alarm is triggered, then the result still includes the new 
 * state of the clock, but a Nothing-value of Maybe<String> as the
 * second part.
 */
Pair<[C], Maybe<String>> tick([C] clock)

/**
 * Returns the number of calls to the tick function needed until
 * the tick function's result will include a String produced by
 * an alarm. Returns 0 if there are no future alarms.
 */
int ticksUntilNextAlarm([C] clock)

Follow the Design Recipe!

Provide the following testing interface:

/** 
 * Creates a new value of your alarm clock type,
 * which resets itself to the 0 tick when
 * it reaches cycleSize (i.e. the current tick
 * is never equal to cycleSize)
 */
[C] makeAlarm(int cycleSize)

/**
 * Returns the current tick time of the given clock
 */
int currentTick([C] clock)

Part 3#

For this part, you may use higher-order list functions from the standard library wherever applicable

In a file called AlarmClock.java

Based on your work in part 2, make a small user interface for your alarm clocks, using BigBang. One should be able to start the alarm clock with some number of arguments from the command line. There needs to be at least one command-line argument. The rest of the command-line arguments are optional, but, if present, must come in triples, describing alarms, with one triple per alarm. The first argument is the size of the clock’s cycle. For each triple, the first argument is a number, describing the tick at which the alarm should be triggered. The second is either “R” (for recurring) or “O” (for one-time). The third is a String that the alarm is supposed to return on being triggered.

HINT: if you have a main function as in main(String... args) {}, you can pass the arguments to MakeList, as in MakeList(args) to get a ConsList<String> containing all the program arguments.

Your alarm clock should advance by one tick per second (World programs step 30 times per second). The window should be reasonably sized (around 500 x 500 pixels +/- 100 pixels), and display the current tick counter in large font, in clearly visible colours. In smaller font below (but still clearly visible), it should display any text that the most recent alarm in the last 5 seconds (150 steps) has produced.

If the user presses the space bar, it should stop the clock from advancing, until the user presses the space bar again, and any text from an alarm that is currently visible should also stay and not decay.

Design the relevant parts of the world program, and follow the Design Recipe!

Provide the following testing interface:

// [W] represents whatever type you use to represent 
// the state of your world

/** your key event handling function */
[W] keyEvent([W], KeyEvent)

/** your stepping function */
[W] step([W])

/** your drawing function */
Image draw([W])

/** returns the initial state of your world */
[W] getInitialState()

/** returns the state of the clock in the given world */
[C] getClock([W])

Part 4#

In a file called Permutations.java

For this part, you must use higher-order list functions from the standard library

Based on the functions in Part 1, design the following function:

/**
 * Returns all possible permutations of the given list, in
 * lexicographic order. For simplicity, you can assume that
 * there cannot be repeated elements in the input list.
 */
ConsList<ConsList<Integer>> permutations(ConsList<Integer> list)

Follow the Design Recipe!

Tasks 1 and 4 were adapted from a course created by Mitchell Wand, though anything that is wrong with them is our fault. The relevant license can be found here.

Updates#