Homework 6
Last updated: Tue, 10 Mar 2026 09:19:33 -0400
Out: Tue Mar 10 2026, 11am EST
Due (after Spring Break): Tue Mar 24 2026, 11am EST
Overview
This assignment gives more practice using list functions, and also introduces accumulators.
This hw will be graded accordingly:
correctness (Autograded) (10 pts)
design recipe (16 pts)
testing (16 pts)
style (16 pts)
README (2 pt)
Setup
Create a new repository for this assignment by going to the CS450 Spring 2026 GitHub Organization and clicking "New".
Note: The CS450 Spring 2026 GitHub Organization must be the owner of the repository. Please do not create the repository in your own account.
On the "Create a new repository" screen:
Name the repository hw<X>-<LASTNAME>-<FIRSTNAME> where <X> is the current homework number.
For example, I would name my hw6 repository hw6-Chang-Stephen.
Mark the repository as Private.
Check "Add a README file".
Select the Racket template for the .gitignore.
Choose whatever you wish for the license.
When done click "Create repository".
Updating Racket450
Make sure you have the latest version of racket450.
To do this from DrRacket, go to File -> Package Manager -> Currently Installed, search for "racket450", and then click "Update".
Alternatively, if you prefer the command line, run:
raco pkg update racket450
Reading
Read Chapters 14-16 of the Textbook, and also the sections on accumulators 31.1 and 32 (where reading means trying to work through the examples and exercises interactively).
NOTE: The textbook will refer to "Student Languages" which we do not use in this course (and a "Stepper" that only works with the Student Languages). Instead, we use a version of Racket tailored for this course, which is invoked by putting #lang racket450 at the top of a file (see also Before Submitting).
Also, read any relevant sections of the The Design Recipe section of the course website, e.g., the Abstraction Recipe and accumulators (topics that will be covered in future lectures are marked as such).
Tasks
The main code should go in a file named hw6.rkt that uses #lang racket450, as described previously.
NOTE, on using previous code: All assignments are designed so that it is quicker to complete them if you start from scratch and follow the Design recipe. No previous code or "solutions" to previous assignments are needed to complete any assignment. Do not attempt to complete this assignment by starting with some pile of code (from a previous assignment or anywhere else) and trying to "make it work". Doing this is almost always slower and you might not be able to finish the assignment on time if you do it this way (it also leads to tedious bugs that are hard to find and impossible to give help to). Finally, not following these instructions demonstrates a lack of understanding of course concepts—
which focuses on the high-level programming process and not the final code— and thus will receive a low grade.
NOTE, on not automatically running code: The submitted program must be only a series of defines (both constants and function definitions are allowed). It should not run any code (e.g., it should not start a big-bang loop automatically!), other than check-equal? Examples. Not following this will result in GradeScope errors and/or timeouts.
As usual, all submitted code must follow the The Design Recipe. This means that language features may only be used in the correct scenarios, as called for by The Design Recipe.
For example, set! and other "imperative" features are not allowed ever.
Conditionals such as if and cond are only to be used with the appropriate Data Definitions or in other appropriate scenarios described in class.
Signatures should use define/contract and the predicates defined in the Data Design Recipe step. In this assignment, you may use the listof contract constructor where appropriate.
For Examples and Tests, do not use check-expect from the Beginning Student Language (even though the textbook says to). Instead, use check-equal? or other testing forms from rackunit (which are built into racket450, so do not explicitly require rackunit).
Examples for a function definition should be put before the define in hw6.rkt.
Tests should be put a into hw6-tests.rkt file that uses #lang racket450/testing. Try to think about corner cases and code coverage.
NOTE, on one-line helper functions: If the name and description of a "helper" function clearly describe what it does, and it clearly follows some Data Definition and all other Design Recipe steps (the course staff is the final arbiter of this), it does not need to be submitted with Examples and Tests if they are covered by other tests. ("Helper" functions are defined as functions not described in the homework assignment description.) NOTE: This does not change the Design Recipe. It is only changing submission requirements. As usual, however, we will not be able to help debug code that does not follow the Design Recipe, so omit these steps at your own risk.
All other functions should have at minimum one Example and "sufficient" Tests.
High-Level "Game" Specifications
This assignment will only involve "Players" and "Cards". New in this assignment: there are different types of cards.
Cards have "Costs" to acquire, are worth "Points", and have a "Color".
Players can have "Tokens" of various colors—
"red", "green", or "blue"— and also any number of "Cards". Owning a card of a certain color can be used to help acquire new cards. More specifically, a player can acquire a new card if: for each token color in the new card’s cost, a player can acquire the card if their tokens of that color, plus cards of that color, is greater or equal to the new card’s cost.
New in this assignment: the different types of cards may have additional requirements when attempting to acquire them (see below).
Data Definitions
The first step of any programming task is Data Design, i.e., defining the data types that the code will operate on. Do not start writing any code until you have done this Data Design step.
this assignment must use the followung Card data definition
A Card is one of:BasicCard
RareCard
GoalCard
You will need to decide the details, e.g., the interpretation, etc, of each of the different card subtype data definitions above, butvery card has the following attributes:a color that is one of "red", "green", and "blue"
- a "Cost" to acquire the card. You are free to design this piece of the data however you wish, e.g., as a separate data definition, or not, but it should follow the Data Design Recipe and have the following components:
a "red" cost,
a "green" cost,
and a "blue" cost
Each color cost should be an integer in the interval [0, MAX-COST], where MAX-COST = 4.
In addition, the various cards have the additional card-specific attributes:a RareCard has an integer point value in the interval [0, MAX-POINTS], where MAX-POINTS = 5. It also has an additional "cost" to acquire, which is that a player must already own a card of its color
a GoalCard has an integer point value in the interval [0, MAX-POINTS], where MAX-POINTS = 5. It’s "cost" to acquire may only be "paid" by owning the appropriate number cards of the same color.
a Data Definition named Player that represents a player in the game.
You will need to decide what this data definition represents, i.e., the interpretation of this data definition, and there may be more than one choice.
But the data definition should at least have the following information:the player’s red token count
the player’s green token count
the player’s blue token count
the player’s cards. This should be represented as a list and the cards should be sorted in order that they are acquired, where the head of the list is the most recently acquired card. The checked constructor should use the (listof Card?) contract for this piece of the data definition
You are allowed to define any other Data Defintions as you see fit
big-bang Functions
This assignment will not use big-bang, so there are no big-bang functions to define.
List Functions
You will need to write the following functions that compute on lists. For this assignment, you should only use the list functions from racket/list such as map, filter, foldr/foldl, etc (except for the one exception indicated below). In other words, you may not use the following list constructors and accessors in function definitions (except for the one exception indicated below) (but you may use them in Examples and Tests:
a function card-points with Signature represented by contract (-> Card? exact-nonnegative-integer?) that computes point value of a card. It should output zero if the given Card does not have a point value. This function should follow the template for Card data only.
a function sum-points with Signature represented by contract (-> (listof Card?) exact-nonnegative-integer?) that computes the total points of all the given cards. It should use card-points
a function sum-points/bonus with Signature represented by contract (-> (listof Card?) exact-nonnegative-integer?) that computes the total points of all the given cards with the following bonus condition: the point value of a RareCard is equal to its base point value, plus one bonus point for each BasicCard acquired after it. You may assume that the input is sorted in order of acquisition where the head is most recently acquired.
This function must follow the accumulator Recipe. The accumulator function(s) should follow a list template where appropriate. This is the only function in this assignment that may use cons, first, rest, etc.
a function player-can-acquire? with Signature represented by contract (-> Player? Card? boolean?) that computs whether a given card could be acquired by a player. Remember to follow the rule for writing small functions: a function should only do one task that processes one kind of data. Thus, make sure to define helper functions where appropriate.
API for Grading
Finally, define the following accessor functions so your submission may be properly tested and graded for correctness. These functions do not need to follow the Design Recipe, e.g., you may combine several templates if needed.
But these functions are only allowed to do "arithmetic". That is, they may only call other functions. They may not do any list processing.
mk-Basic/test with contract (-> image-color? exact-nonnegative-integer? exact-nonnegative-integer? exact-nonnegative-integer? Card?) that ouputs a BasicCard with the given color, and red, green, blue costs, in those order of arguments.
mk-Rare/test with contract (-> image-color? exact-nonnegative-integer? exact-nonnegative-integer? exact-nonnegative-integer? exact-nonnegative-integer? Card?) that ouputs a Card with the given color, and red, green, blue costs, and points, in those order of arguments.
mk-Goal/test with contract (-> image-color? exact-nonnegative-integer? exact-nonnegative-integer? exact-nonnegative-integer? exact-nonnegative-integer? Card?) that ouputs a Card with the given color, and red, green, blue costs, and points, in those order of arguments.
mk-Player/test with contract (-> exact-nonnegative-integer? exact-nonnegative-integer? exact-nonnegative-integer? (listof Card?) Player?) that ouputs a Player with the given red, green, blue tokens, and cards, in those order of arguments.
Before Submitting
Testing (and Autograders)
Before submitting, note:
Each programmer is solely responsible for testing their program to make sure it’s correct. Do not submit until all code has been has a "sufficient" number of Test cases that verify its correctness.
Note that there is no GradeScope "Autograder" available for students to use (an Autograder is not a software development/testing tool anyways, so it should not be used as one).
Thus, no questions mentioning an Autograder will be answered, e.g., posts asking "why is the Autograder giving an error?" are not allowed.
If you happen to find an Autograder and decide to look at its output despite this warning, please understand that it may be incorrect or incomplete, change at any time, or have random behavior, and that it in no way indicates the grade of the submitted hw.
Anyone that does get useful information from an Autograder, e.g., a failing test case or crashing code report, should treat it as bonus information (that you otherwise would not have had) that you and you alone must determine what to do with.
Regardless of what any Autograder might say, all code must still be independently tested to be correct before it is submitted.
The proper way to ask questions is with small code examples. This means that each question must include a small example code snippet along with what the "expected" result should be!
Further, any posted examples should contain the minimal amount of code needed to explain the question. Full file dumps or anything more than a few lines will not be accepted. More is not better. In fact it’s worse because it takes longer to read and is less likely to get a good answer.
Style
All code should follow proper Racket Style.
Also, the repository itself must follow proper style. Specifically, it must have appropriate commit messages. See How to Write a Git Commit Message if you are unsure how to write a commit message.
Note: Do not use the "file upload" feature on Github. The course staff may not accept hw uploaded in this way.
Files
A submission must have the following files in the repository root:
hw6.rkt: Contains the hw solution code.
The first line should be #lang racket450.
All defines should use the name specified in the exercise (ask if you are unsure).
hw6-tests.rkt: This file should use the #lang racket450/testing language.
It should also require hw6.rkt and define tests for it.
Specifically, it should contain "sufficient" Test cases (e.g., check-equal?, etc.) for each defined function.
README.md: Contains the required README information, including the GitHub repo url.
Submitting
When you are done, submit your work to Gradescope hw6. You must use the "GitHub" Submission Method and select your hw<X>-<LASTNAME>-<FIRSTNAME> repository.
Note that this is the only acceptable way to submit homework in this course. (Do not manually upload files and do not email files to the course staff. Homework submitted via any unapproved methods will not be graded.)
