Skip to main content

Day 3 - Definitions

Skills: None​

Pre-reading: 3.2​

Intro (10 mins)​

Goal Understand how to create & use names (identifiers), and program directory.

  • Review "definitions" window for permanent work, "interactions" window for testing it, trying things out, etc.
  • While we've been using the definitions window to write down expressions, and see them printed out when we hit Run, the primary use is actually to write named definitions, like: 
    blue-square = rectangle(40, 40, "solid", "blue")
  • When we hit Run, initially, nothing seems to happen, but now if we type blue-square in the interactions, we see a blue square image.
  • Running caused everything in the definitions pane to evaluate, including the rectangle expression above, which evaluated to a blue square. The definition statement blue-square = ... caused the resulting value to be stored under that name so we can refer to it later.
  • IMPORTANT: names & strings are different! "blue-square" is not the same as blue-square.
    • What do you think will happen if you type puppy versus "puppy" at the prompt?
  • We can understand how our programs work, and how definitions work, by understanding that our program has a directory that records names and values.
  • Every definition statement, written name = expression causes expression to be evaluated and name to be added to the directory, so it can be used later, including in other expressions for other definitions.
  • e.g., you can write radius = 10 and then area = 3.14 * radius * radius. If you do those in the other order (TRY IT), it won't work, since the directory won't have the radius entry yet.

Class Exercise (40 mins)​

  • Define an an orange triangle with side length 35. Now evaluate the identifier (i.e., orange-triangle) in the interactions pane.

  • Define a side length and color (as two separate definitions), and then define a square using those names for the side length and

  • Now define a second version where you do not use the side length and color variables. Notice that when you evaluate both identifiers in the interactions, they are exactly the same, but the code is easier to read with the separate definitions.

  • Try defining a new side length with the same variable, later in the definitions. Note what happens when you try to hit "Run". Redefining the same variable is called "shadowing", and Pyret rules this out, since it is a common cause of bugs.

  • Now define an image that has a small yellow circle on top of a larger black rectangle. Try several different ways, using different number of definitions. See which is easiest to understand.

  • Go back to your previous examples and see if there are other definitions you can add. Did you make definitions for the radius of circles you made? The length of your orange triangle? Try changing the code to include all of those.

  • If you make a definition for the color of your orange triangle, what did you name it? If you want to change the color of the triangle, will you have to change the name of the definition (i.e., if you used orange, but wanted to make the triangle purple, you should probably change it to purple = "purple")? If so, that's an indication that perhaps the definition was not helpful, or didn't have a good name. Having to change the definition name means you will also have to change the uses of the definition!

  • Now make a new image that puts two copies of your small yellow circle side-by-side on top of your black rectangle.

  • Now think of a simple flag or logo design. Sketch out a plan on paper and come up with names for different parts of the design. If you have time, make definitions for each part, and compose them together to make the final image.

Wrap-up (5 mins)​

  • Definitions involve the first aspect of program design. Notice how there were often many different ways of writing the same program, some of which were easier to understand, easier to modify, and even possibly easier to write.
  • One of the main lessons of this class, and indeed this whole curriculum, is that well designed code is something much more important, and often more challenging, than just getting code to work. Of course code has to work, but for it to work in real systems, at the scale that we are building them, messy, convoluted, or confusing code can make it so hard for people to understand what is going on that even getting it to work, as the programs get bigger, becomes impossible.
  • By focusing on design, from the very beginning, you'll develop skills that will help you all the way through, as programs get bigger and bigger!