Contracts

Students learn how to apply functions in WeScheme, and are introduced to the notion of Contracts: a simple notation for keeping track of all possible input and output sets for a function.

In human languages, verbs do things to nouns. For example, I can "throw a ball", or "eat a sandwich". "Throw" and "Eat" are verbs, and "ball" and "sandwich" are nouns.

In programming languages, values are like nouns. You’ve learned about different data types in our programming language, like Number values (42, -8.3, etc), String values ("hello!"), and Boolean values (true and false).

In programming, most verbs are called functions. A function is like a machine at a factory:

Let’s play with a function to get the hang of it.

Be sure to read any error messages you get back carefully! They might have clues to help you understand what’s going on.

The expressions using the regular-polygon function produced a value that wasn’t a Number, a String, or a Boolean. In the WeScheme programming language, these values are called Images.

Contracts are binding agreements! For example, we might sign a contract with a plumber to install a sink for $200. As long as they install the sink, we are obligated to pay them $200. If a parent promises to order pizza if their child does their chores, they’d better order that pizza if the child does those chores!

If one party breaks the contract, bad things can happen. In some programming languages, breaking a function’s contract can cause the whole computer to crash, or it can result in a security hole that lets the program be hacked! In WeScheme, the contracts are checked every time to use a function, so the only result is a helpful error message.

We’ve just encountered a lot of new vocabulary! Solidify your understanding by working through Domain and Range and/or Function and Variable to explain these ideas in your own words, using these Frayer Model visual organizers.

Contracts don’t tell us specific inputs. They tell us the general data type of each input that a function needs.

It would be silly for a function to only work on a single, specific input! For example, the Contract for string-length says it takes in a String, as opposed to a specific string like "rainbow". We could use any value at all…​as long as it’s a String. When writing code, however, we plug specific values into the expression we are coding. Contracts give us a big hint about what those specific values need to be.

Arguments (or "inputs") are the values passed into a function. This is different from variables, which are the placeholders that get replaced with those arguments!

This activity focuses on what we can learn from error messages when a Contract is broken. The error messages in this environment are specially-designed to be as student-friendly as possible.

Encourage students to read these messages aloud to one another, and ask them what they think the error message means. By explicitly drawing their attention to errors, you will be setting them up to be more independent in the future.

Mistakes happen, especially if we’re just figuring things out! Let’s see how error messages in WeScheme can help us to figure out the contract for a function we’ve never seen before.

This means that the computer knows about a function called triangle.

Diagnosing and fixing errors are skills that we will continue developing throughout this course.

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.

In order to make sure that all students both remain engaged and are prepared to engage in productive class discussion, when you become aware that the first student in your class has successfully used the text function, give your class directions about which functions to prioritize with the remaining time.

If your students are ready to dig into more complex triangles, Triangle Contracts (SAS & ASA) will be a good challenge. Another option for further investigation is Star Polygon.

If you see an error and you know the syntax is right, ask yourself these three questions:

Students learn to work with more than one function at once, by way of Circles of Evaluation, a visual representation of the underlying structure.

What if we wanted to see your name written on a diagonal?

; text :: (Stringmessage, Numbersize, Stringcolor) -> Image

; rotate :: Number, Image -> Image

But how could the rotate and text functions work together?

One way to organize our thoughts is to diagram what we want to do, using the Circles of Evaluation. Circles of Evaluation help us think about what we want to do, without worrying about syntax like quotation marks, parentheses, etc. They let us use all our brains for thinking, before we use them for coding.

The rules are simple:

(1) Every Circle of Evaluation must have one - and only one! - function, written at the top.

(2) The arguments of the function are written left-to-right, in the middle of the Circle.

(3) Circles can contain other Circles!

Suppose we want to see the text "Diego" written vertically in yellow letters of size 150. Circles of Evaluation let us see the structure.

To convert a Circle of Evaluation into code, we start at the outside and work our way in. After each function, we write a pair of parentheses, and then convert each argument inside the Circle.