Contracts

Students learn how to apply functions in WeScheme, reinforcing concepts from standard Algebra, and practice reading error messages to diagnose errors in code.

Students know about Numbers, Strings, and Booleans — all of which behave just like they do in math. But what about functions? Students may remember functions from algebra: fx = x + 4$\displaystyle f(x) = x + 4$.

Arguments (or "inputs") are the values passed into a function. This is different from variables, which are the placeholders that get replaced with input values! Pyret has lots of built-in functions, which we can use to write more interesting programs.

Have students log into WeScheme, open the editor, type (sqrt 16) into the interactions area and hit Enter.

Have students type (string-length "rainbow") into the interactions area and hit Enter:

Have students complete Applying Functions (Page 17) to investigate the triangle function and a series of error messages. As students finish, have them try changing the expression (triangle 50 "solid" "red") to use "outline" for the second argument. Then have them try changing colors and sizes!

Debrief the activity with the class.

This activity introduces the notion of Contracts, which are a simple notation for keeping track of the set of all possible inputs and outputs for a function. They are also closely related to the concept of a function machine, which is introduced as well. Note: Contracts are based on the same notation found in Algebra!

When students typed (triangle 50 "solid" "red") into the editor, they created an example of a new data type, called an Image.

The triangle function can make lots of different triangles! The size, style and color are all determined by the specific inputs provided in the code, but, if we don’t provide the function with a number and two strings to define those parameters, we will get an error message instead of a triangle.

As you can imagine, there are many other functions for making images, each with a different set of arguments. For each of these functions, we need to keep track of three things:

The Name, Domain and Range are used to write a Contract.

Where else have you heard the word "contract"? How can you connect that meaning to contracts in programming?

An actor signs a contract agreeing to perform in a film in exchange for compensation, a contractor makes an agreement with a homeowner to build or repair something in a set amount of time for compensation, or a parent agrees to pizza for dinner in exchange for the child completing their chores. Similarly, a contract in programming is an agreement between what the function is given and what it produces.

Contracts tell us a lot about how to use a function. In fact, we can figure out how to use functions we’ve never seen before, just by looking at the contract! Most of the time, error messages occur when we’ve accidentally broken a contract.

Contracts don’t tell us specific inputs. They tell us the data type of input a function needs. For example, a Contract wouldn’t say that addition requires "3 and 4". Addition works on more than just those two inputs! Instead, it would tells us that addition requires "two Numbers". When we use a Contract, we plug specific numbers or strings into the expression we are coding.

Let’s take a look at the Name, Domain, and Range of the functions we’ve seen before:

Optional: Have students make a Domain and Range Frayer model (Page 18) and use the visual organizer to explain the concepts of Domain and Range in their own words.

Have students complete pages Practicing Contracts: Domain & Range (Page 19) and Matching Expressions and Contracts (Page 20) to get some practice working with Contracts.

This activity digs deeper into Contracts. Students explore image functions to take ownership of the concept and create an artifact they can refer back to. Making images is highly motivating, and encourages students to get better at both reading error messages and persisting in catching bugs.

(If needed, you can print a copy of these contracts pages for your students.)

Students are given contracts for some more interesting image functions and see how much more efficient it is to write code when starting with a contract.

You just investigated image functions by guessing and checking what the contract might be and responding to error messages until the images built. If you’d started with contracts, it would have been a lot easier!

Have students turn to Using Contracts (Page 21), Using Contracts (continued) and use their editors to experiment.

Once they’ve discovered how to build a version of each image function that satisfies them, have them record the example code in their contracts table. See if you can figure out what aspect of the image each of the inputs specifies. It may help you to jot down some notes about your discoveries. We will be sharing our findings later.

Have students turn to Triangle Contracts (Page 22) and use the contracts that are provided to write example expressions. If you are ready to dig into triangle-sas, you can also have students work through Triangle Contracts (SAS & ASA).

Sometimes it’s helpful to have a contract that tells us more information about the arguments, like what the 3 numbers in a contract stand for. This will not be a focal point of our work, but to give students a taste of it, have them turn to Radial Star (Page 23) and use the contract to help them match the images to the corresponding expressions. For more practice with detailed contracts you can have them turn to Star Polygon to work with the detailed contract for a star-polygon. Both of these functions can generate a wide range of interesting shapes!

Make sure that all students have completed the shape functions in their contracts pages with both contracts and example code so they have something to refer back to.

Students are very likely to randomly experiment, rather than to actually use the Contracts. You should plan to ask lots of direct questions to make sure students are making this connection, such as: