Structuring and Evaluating Code

Copyright (c) 2017 Kathi Fisler

1 The Jamaican Flag

We started by having everyone put up their solutions to the Jamaican flag, so we could see the various approaches. The ideas raised included:

• There are many ways to write this program

• There are many ways to see the substructure of the flag: is it four triangles on a background, is it a shape that gets flipped and composed several times, how many shapes, etc

• How descriptive should we make variable names?

• Which operators should we use? overlay, align, flip, etc?

2 Code Structure: Emoji code

We looked at two versions of a program to draw an emoji face. Our discussion focused on the following issues:

• The first may seem easier to read, since the result of each expression is named.

• But the second may also seem easier to read because the indentation of subexpressions reveals the structure of the computation itself. Structuring computations is one of the major tasks in programming, and having your code reflect the structure of your solution is extremely useful when you (or someone else) has to read your code later.

• Finding a balance between naming (to remember what pieces of a computation do) and nesting (for structure) is a big part of learning how to write good programs. This is something you’ll practice throughout the course.

• There are no significant differences in efficiency between the two versions.

3 How Programs Evaluate: Ice Cream

Imagine that you had the following contents in the definitions window (the one on the left):

How will Pyret evaluate this program?

• Pyret processes the expressions one at a time from top to bottom

• When Pyret encounters something of the form name = expr, it creates an entry in an internal dictionary. The dictionary maps names to values. Thus, Pyret evaluates the expression on the right of the =, then makes a dictionary entry to associate the name with that value.

• When Pyret encounters an expression that has other expressions nested within it, it evaluates the sub-expressions from left-to-right and innermost to outermost. Thus, in the flip-vertical expression (that creates the cone), the first expression to evaluate is SCOOP-SIZE (which Pyret looks up in the dictionary), then Pyret computes 15 * 2, then it creates the triangle, then flips the triangle.

  In the longer overlay-xy expression, the pink circle gets created before the green circle (by the left-to-right rule).

You may have noticed that SCOOP-SIZE is all in caps, while cone is in lowercase. Conceptually, SCOOP-SIZE is a key concept in the program (which we plan to use multiple times), whereas cone is just naming an intermediate computation for readability. We use this naming convention to help us remember the respective roles of the names in the program.

3.1 What does the Run button do?

When you press the Run button, Pyret erases the dictionary then re-processes the definitions window from the beginning. Any dictionary entries that you made only in the interactions (right) window disappear.

3.2 Errors

We discussed error messages and what they might tell us about the order of how Pyret processes code. Pyret actually processes your code in two passes: in the first pass, Pyret checks whether any names would be used before they are added to the dictionary, but it doesn’t perform any computations or actually create any dictionary entries. If all the referenced names would be properly defined, then Pyret runs the expressions from top to bottom.

4 Expressions versus Statements

We’ve already seen that there’s a difference between

and their impact on the interactions window: the first adds to the dictionary, while the second displays a value. A piece of a program that changes how future expressions will evaluate is called a statement. Creating a name meets this definition, since expressions will yield errors or not depending on whether a name appears in the dictionary. Expressions perform computations without changing the information that Pyret maintains for running future expressions.

This distinction will become more meaningful later in the course, but we’ll use the terminology to get used to it now.

4.1 Key Takeaways

The theme of this segment is how code can reflect the structure of data or computations. The structure of an image is reflected in which smaller images you use to create it; the structure of a computation is reflected in which operations you choose and how you nest them. Computer scientists look for structure in data and problems, then capture that structure in code so others can see what structure they had in mind.