Homework 3🔗

Last updated: Mon, 23 Sep 2024 10:42:43 -0400

Out: Mon Sep 23, 2024, 12pm (noon) EST

Due: Mon Sep 30, 2024, 12pm (noon) EST

Overview🔗

This assignment continues to explore programming according to the The Design Recipe, a systematic way to write programs that are both correct and readable. In particular, we’ve now learned about many different kinds of Data Definitions, e.g., itemizations or compound data, so you should be thinking about how you can utilize them.

This hw will be graded accordingly:

Setup🔗

Create a new repository for this assignment by going to the CS450 Fall 2024 GitHub Organization and clicking "New".

Note: The CS450 Fall 2024 GitHub Organization must be the owner of the repository. Do not create the repository in your own account.

When done click "Create repository".

Tasks🔗

Reading

• Read Chapters 4-5 of the Textbook (where reading means working through the examples and exercises interactively).

• Review the The Design Recipe section of the course website (topics that will be covered in future lectures are marked as such).

NOTE: All code you write must now follow the The Design Recipe. (Just submitting code is no longer sufficient.) Signatures should use define/contract and the predicates defined in the Data Design Recipe step.

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.

Examples for a function definition should come right after the define. But Tests should be put into the test-suite in tests.rkt. Try to think about corner cases and code coverage. (I may run your test suite against the code of other students and award bonus points for bugs found.)

In this assignment, each function should have at minimum of one Example, and one more Test than Examples (so two minimum tests).

Also, remember that Racket Style and The Design Recipe reserves certain language features only for specific scenarios. For example, set! and other "imperative" features are not allowed ever. Conditionals such as cond should only be used with enumeration or itemization Data Definitions.

Programming

In this assignment we’ll extend the "Guitar Hero"-like big-bang interactive program from Homework 2 with a key handler.

Here is an online demo that approximates the behavior of the program.

Tests should go in a tests.rkt file, as described in lecture and the hw3 starter code, and the rest of the code should go in a file named hw3.rkt.

NOTE: The submitted program must be only a series of defines (both constants and function definitions are allowed) and check-equals?. It should not run any code. Not following this this will result in GradeScope errors and point deductions.

NOTE: You may look at prior code and examples to help you but BE CAREFUL. A "COPY-AND-MODIFY" PROGRAMMING STRATEGY WILL NOT WORK IN THIS COURSE (nor in the real world). Your program will be wrong (partially because most of the design recipe steps will be wrong) and will receive a low score. Instead, you should write the code for this homework from scratch using The Design Recipe.

• Start with a big-bang program that is a 200\times 200 pixel scene where a 40\times 80 (width \times height) green solid rectangle moves across the screen from left to right at a rate of 2 pixels per tick. The "y" coordinate of the rectangle should be centered in the scene.

  The initial scene should have the rectangle left side touching the left border of the scene.

• When a part of the rectangle goes out of the scene on the right, that part should appear to wrap around and re-appear on the screen on the left.

• The scene should also have a gray vertical line in the middle that does not move. When the rectangle and line intersect, the rectangle should appear to be on top.

• Add a key handler function such that when the space button is pressed and the rectangle is touching the middle line, the rectangle changes from "solid" to "outline" fill, and vice versa.

• More specifically, your program should define and provide the following:

  Constants

  • SCENE-WIDTH = 200

  • SCENE-HEIGHT = 200

  • INIT-RECFILL = "solid"

  • REC-WIDTH = 40

  • REC-HEIGHT = 80

  • REC-CENTER-Y = 100

  • INIT-REC-X = the x-coordinate of some point representing the rectangle (of your design)

  • INIT-WORLDSTATE = the initial WorldState (of your design)

  • EMPTY-SCENE = an empty-scene with the middle line drawn but no rectangle

  Data Definition(s)

  • A Data Definition named WorldState that represents your chosen world state values of your big-bang program

  • You probably also want to create data definition(s) to represent the current location of the rectangle and its fill state (and these should probably be part of a WorldState value)

  Functions

  • WorldState-x : a function that takes a WorldState value and returns a number representing the x-coordinate of some point in the rectangle (will vary depending on your data design)

  • WorldState-recfill : a function that takes a WorldState value and returns "solid" or "outline" depending on the current state of the rectangle

  • render-rec : draws an appropriate rectangle for the scene, given a fill mode

  • key-handler : 2htdp/universe key handler that responds to "space" presses as required

  • toggle-recfill : given a rectangle fill, returns the other one, and vice versa

  • get-rec-center-x : given an x-coordinate of some point representing the rectangle (will vary based on your data design), compute the center x-coordinate of the same rectangle

  • WorldState? : predicate that returns true when given a value that is a valid WorldState

  • next-WorldState : function with signature WorldState -> WorldState that is given to big-bang as the on-tick function

  • render : function with signature WorldState -> Image (where Image is a built-in basic data definition from 2htdp/image; (image? i) evaluates to true for i that are valid instances of Image) that is given to big-bang as the to-draw function.

  • a function main that takes no arguments and starts the big-bang interactive loop

Before Submitting🔗

Testing

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.

Files

A submission must have the following files in the repository root:

• hw3.rkt: Contains the hw solution code.

  All defines should use the name specified in the exercise (ask if you are unsure) and should be provided.

  The easiest (but not always the most readable) way to ensure all necessary definitions are provided is to (initially) put as the second line in the file:

  (provide (all-defined-out))

  This automatically provides all definitions in the file. (The first line should be #lang racket)

• tests.rkt: This file should require hw3.rkt and define tests for it.

  Specifically, it should define a rackunit test-suite which contains sufficient rackunit 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 hw3. 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.)