Speaker 1: The following is a video tape module from the learning system Seymour Papert On Logo. The tape series has two parts. The first, New Mindstorms, focuses on the process and the principles of learning. The second, Logo Hurdles, focuses on specific technical aspects of Logo. This is Hurdles tape number two, Names and Variables. Like the other Hurdles modules, it is intended for use with On Logo study guides and computer diskettes.
Seymour: Ever wondered why we chose those symbols, quotes and dots for Logo? I’ll tell you. Quotes are like two fingers, they’re the two marks. Dots are like two eyes, on the side, all the same, same thing. Well, you might say, what’s that got to do with it? What’s that explain? I’ll tell you. It’s like this. Suppose you need some muffins, and suppose I want to oblige, there are three Logo-like things I can do. I could take one of these muffins I’ve just baked, and give it to you, see, on two fingers. Think of PRINT “CAT. The quote marks take the word cat and give it to Print. Print gets its input directly. Or I could do :Muffins. That’s an [activity 00:02:15] they call Muffins.
You know, maybe you didn’t know. Maybe you speak some other language. And then it says, use your eyes. Because if you know what they’re called, and use your eyes, you’ll go over and look at the jars, donuts, muffins, cookies. In the muffins jar, you’ll find muffins. And then there’s the third way, I would give you the recipe, that’s how to procedure in Logo. Where you would break your own eggs, you’d beat it with milk, you would put in flour, baking powder, melted butter. You’d put it in the oven, and after a while you’ll have muffins. Well, I bet you don’t believe me. It doesn’t matter. This little story is an excellent metaphor for thinking how Logo works. Now, leave it and contemplate it while you enjoy the muffins.
Well, let’s try and apply these muffin ideas in a more regular Logo situation. You’d be surprised at how much easier it makes learning Logo to have a consistent language for talking about, and thinking about, and teaching about Logo punctuation marks. I mean, these quotes, open list, closed list, dots. I have a way of talking consistently. I say, print, quote, square, and I say, square is a quoted word. Print, list, a square. And I say that, a square, these two words are packaged in a list. I’ll say, print, dots, square. Or print, thing of square. And I say, square is dotted. And even in this case, where there’s no explicit punctuation mark, it’s quite important to have a name for it. I say, here square is unadorned. The advantage of having names for all four situations is that, these are the four ways that a word can occur in Logo. Logo has four different, and only four, ways of treating a word, depending on which case you’re in.
Having this category helps you organize your ideas. In this tape I’m going to concentrate on the dots, the dotted words. I’m going to assume that you at least know what happens when PRINT “SQUARE, and PRINT [A SQUARE], are run as instructions. I’d like to draw attention to just one aspect. You don’t have to know any past history in order to know what will happen in this case. You can walk up to any Logo, it doesn’t matter what anyone has been doing to it, type this, and you know what will happen. Not so for this case. In this case our work on output and reporters has shown us how to think about it. Print asks square for an input. The unadorned word is always treated as if it were a procedure.
Print runs the procedure in the hope of getting an input, but its hope might be frustrated for a number of different reasons. First, there may not be any such procedure. If it wasn’t defined, we’ll get an error message. Something like, I don’t know how to square. Or perhaps there is such a procedure, but it’s not a reporter, so it doesn’t report anything to print, and we’ll get another error message. So that, in these cases, something much have happened before, in order for these instructions to work. And what happened before makes a difference to how the instructions work. I’m going to focus on the kind of thing that happens in order to make this instruction work. I’m going to call it naming.
Let’s take an example here. Suppose I’ve said, Name 2 “Green. Name is a Logo command. It’s given a name to this Logo thing, the number 2. That name is Green. And when you’ve given this command, PRINT :Green, will print 2. Sometimes the instruction, MAKE “Green 2, is used in place of this. I really think quite a lot of confusion comes from that, especially with young children. I’m going to try to show you how this way of thinking about it is highly [Simtonic 00:06:41], rich in connections with everyday life situations. Whereas this one is very abstract, not connected to very much. Let’s look at the same situation on a computer screen.
Most versions of Logo in the original form use numerals to obtain color effects. For example, in this version of Logo, set background 2, will make the background green. Some people find it annoying to remember these numbers. And naming such as this one will give the color name green to the number 2. So that we can then give commands like, SETPC :Green. Or SETBG :Green. And the turtle will change its color, or the background, or whatever, without our having to use the numerals. The same idea can be extended to write a procedure, name colors, for example, which can be used at the beginning of the session to set up color names for all the numerals. I used four here, only not to clutter the screen, you would use as many as there are colors in your version of Logo.
Once you’ve done that, you can run the procedure, Name.Colors as a tool at the beginning of the session, and then use it to get effects, such as this. You see here we didn’t have to use numbers, we could say, SETBG :BLUE, :GREEN, and so on. By the way, I’ve known many children, and even some teachers, omit this step. As if they thought that defining the procedure would be sufficient to give these names to the appropriate numbers. Of course you’ve got to run the procedure in the particular session in order for it to have its effect. It doesn’t do anything, just sitting there in the workspace without being run.
In Logo naming is quite central. But this is because it’s quite central in all thinking, in all communication or teaching. And this has been captured in Logo. The importance of naming in our lives is reflected in the ceremonial associated with it. The naming of a baby, the champaign bottle at the launching of a ship. In Logo the high priest of naming is the procedure, Name. And I’m going to be name-active for a while. I’ve brought these animals to help act out the way Name works. Dog, I dub thee Fido. As Name, I needed two inputs. This is my first input, a thing. And this is my second input, a name. In all naming situations there are these two elements. This is the thing of this name, and this is the name of this thing. This is a language that is quite essential, that you get into the habit of using. Let’s use the cat to look at some other aspects of naming. I name, this is my first input, the thing of the naming situation, its name, Mcavity. Cat, I dub thee Mcavity. Now, can it have another name?
Can one thing have two names? Well, why not. Let’s try. Cat, I dub thee Jellylorum. Is this a confusing situation in any way? I don’t think so. We use names to refer to things. If I say Jellylorum, you know which thing I mean. This one. If I say Mcavity, you know which thing I mean. This one. And so in Logo two, one object, one thing, can have many names. For example, in Logo there are no cats, no dogs, but there are numbers. And we saw how the number 2 could be called Green. Two, I dub thee Green. We can also give it another name. Two, I dub thee Duo. And if we did that PRINT :GREEN, or PRINT :DUO, it would make 2 appear on the screen. But what about two things having the same name? That’s more confusing. Suppose that this lion were called Seymour.
Somebody said Seymour. How do we know whether it meant this thing, me, or this thing, the lion? In real life we deal with this confusion. In a class, if you have two boys called John, you invent an [experian 00:11:32] for distinguishing between them. But in Logo, in general, we don’t allow it. When Name gives the name Seymour to this lion, it would take it away from me. That’s what happens in general. In the latest segment we’ll talk about local naming, which is rather analogous to the fact that, if the lion and I were in different families, in different places altogether, no harm would be done by our having the same name. I’d like to get back to Logo a little. As I’ve said, we don’t have cats and dogs, and as you know, what do we have? Numbers, of course.
Numbers are special examples of what we call words in Logo. And besides words, we have one other kind of thing. Lists. And they too can be named. For example, this is … I’m being named now, my one input, a list. Here’s my other input, it’s a word, which I can use as a name. List, I dub thee Animals. And now PRINT :ANIMALS will make this list appear on the screen. This is the thing, and this is the name of a naming situation in Logo, just like those we had with the animals. To use an idea you must understand it, surely. But to understand an idea you must just as surely use it. The art of learning is a spiral art. To find understandings that are limited enough to be accessible at the beginning, you have to write enough to support real users. From real users a fuller understanding will grow.
If you really understand Logo, you’ll know that in it, only Logo things can be named. For example, you can’t name a lion, but you can name the word lion, because words are Logo things, and so are lists. But nothing else. Yet, I want to take you on an exercise, in which we’ll deliberately restrict our understanding, and talk as if we’re naming something else. A position, a place on the screen. I’m going to use naming as a geometric technique for drawing this picture. Everything in it is very straightforward, except for that triangle. How do you draw a triangle like that? Everybody knows how to draw equilateral triangles in Logo, when the three sides are all equal, and the angles are equal too, 120. But a triangle like that requires a different technique.
Let’s see how it works. Here’s the total drawing, the easy part of the church. Now, there it sits, waiting to draw the triangle. This is where you’re going to use our geometric smartness. We named the place where it’s sitting, NAME POS, that’s where the turtle is, “LBASE. And then we drive it over to the other side and name that “RBASE, for the right-hand side of the base of the triangle. We’ll then drive it to the peak, of course in Pen Up mode, and we’ll allow ourselves a bit of fishing to find the right position. But when we have, we’ll name that, NAME POS “PEAK. We’ve now named the three vertices of the triangle. The naming will pay off, because if we now do, Pen Down, and then SETPOS :RBASE, it will go back there. And SETPOS :LBASE, and it’ll go there. And finally SETPOS :PEAK will send it to the point named peak. HT gets rid of the turtle, and we can clear our text away.
And so you see how the reported POS can be used by somebody who does not yet understand that what it reports is a list, a list of two numbers, the x coordinate and the y coordinate of a point. Perhaps even by somebody who doesn’t even know that there are such things as coordinates. But the fuller understanding can come through use, much sooner than you think. The next project shows a different aspect of the learning spiral. We’re going to hone in on a key moment in the evolution of a program, the programmer is about to encounter a fruitful bug.
Lauren: Hi, Alex. What are you doing?
Alex: Oh, I’m making this new program. Here, I’ll show you.
Lauren: Hi, my name is Logo. What’s yours?
Alex: Well, it doesn’t know the difference. So I’ll just put in, Sandy Pitt.
Lauren: Sandy is a nice name. What kind of ice cream do you like?
Alex: Well, what kind of ice cream do you like?
Lauren: I like chocolate.
Alex: Okay.
Lauren: It says, My favorite is chocolate. Let’s get both kinds. Some chocolate ice cream, and some chocolate ice cream. It’s kinda nice, but it’s dumb too.
Alex: Well, give me a break, will you? Come back in 15 minutes, and I’m sure it’ll be fixed.
Seymour: If you put yourself empathetically in Alex his position, you see something quite interesting about the evolution of thought processes. Alex knew that his program was going to choose chocolate, and this created a mindset in which he expected the user to say something else. Anything, vanilla, strawberry. And had she done so, the program would not have seemed dumb. Her unexpected response opened a new project for Alex, a debugging project. He couldn’t anticipate the obvious, no one can, thinking words by dialogue between the thinker and something outside, the objects you’re thinking about. I’m going to reconstruct on the screen some key moments in the spiral process of debugging, that carries Alex’s program to the next stage of its evolution.
In this visualization I’ll use color, blue, white and pink to represent three kinds of information. The blue originated with the program. The white originated with the user. The pink originated with the program under the influence of the user. What’s in blue, the program knew in advance, would be typed. What’s in pink is typed in response to what the user typed in. Notice the origin of Alex his problem. Had the user said, vanilla, we would have read, Let’s get both kinds, some vanilla ice cream, and some chocolate ice cream. And all would have been well. As often happens with programming, the user chooses the one response that’s going to give us trouble. Let’s see how we can modify the program to get rid of this problem.
The problem is in a sub-procedure, To Ice Cream, of Alex his program. Let’s see how it was written. Alex noted that it had to begin by typing a message, a question. And then it was going to type something else, a message in three parts. A fixed text we saw in blue. And then in pink we saw what Readlist reported, that the user had typed. And finally, another fixed text. Readlist does make it responsive to what the user typed. But Lauren’s giggle showed that it was responsive in a kind of mechanical way, and we want to fix that. But before looking at the structure of this whole program, I’d like to get rid of some clutter. I note that the content of these texts doesn’t really have anything to do with the structural problem that really interests us.
So I’m going to show you a trick for cleaning up the layouts, so it will look neater, give us more space to work in. I’m going to take each of these messages, and give it a name. So you can refer to it by name, instead of having the actual text there. I start with the first message, What kind of ice cream do you like? And I could give it any name I liked, I’ll call it Question. We do a naming. The thing is this message, What kind of ice cream do you like? And the name is “Question. Another naming, the next piece of text. And we could call it anything we’d like, like T2. I’m going to use the name Favorite, that’s reminiscent for me of what the content is. And finally we take the third part of the text we saw in blue, and give it a name, chosen to recall what it says.
Let’s see how these namings help us tidy up the layout of this program. Notice Print gets its input directly. I’m going to change that. It will get it indirectly as :Question. Neater. We can do it the same down here. This Print can get its third input as :ICE.CREAM. Let’s just move Readlist down, and then do the same thing with its first input, :FAVORITE. Clear that down to give us some space. We have a space there for the new part. What’s that to be? It should be a condition, so write down IF. You don’t know what the inputs to IF are. That’s okay. Always put down what you do know for sure, then face the problems. Okay. Take a guess. Readlist = [Chocolate] It must be on the right lines, because it was when the user typed chocolate that we got into trouble.
What can we do in this case? A procedure, Me.Too, could do something like say, wonderful we have the same taste. But this leaves two bugs. And we can find them by running through, the procedure now heads on two hypotheses. First on the assumption that the user typed chocolate. And second on the assumption that the user typed strawberry. Chocolate first. At this point, Readlist would wait for the user to type something, we’re supposing it’s chocolate. It will be handed to = as its first input. Equals would say, true, [ME.TOO] would be run. Well, that’s what we wanted. But what happens afterwards? Ice Cream had a plan. Its flow of control was this, then this, then this. And after [Me.Too], IF would report, I’m done. And Ice Cream would go on to do this.
So that, after having said whatever Me Too makes it say, it would do the old stuff as well, which is obviously not what we wanted. How do we fix that? We need to put a controller in there. Stop. So that after doing Me Too, Ice Cream stops. It doesn’t do this, it’s as if it came to End, and the program will get on with the job. Now let’s see what happens if user types strawberry. We get false there. Me Too isn’t run. It doesn’t stop. But when we get down to there, something unexpected happens. The computer will wait until the user types something. That wasn’t our intention. We didn’t mean two typings to happen. We didn’t mean there to be two Readlists. And I’m going to show you a trick for getting away with just one Readlist, and using what it reports for multiple purposes. We do a naming.
Name Readlist, whatever you like, “Flavor. “Flavor would name Chocolate, or strawberry, or vanilla, or whatever. Now we take that Readlist, replace it by :Flavor. If the user typed chocolate, :Flavor is Chocolate, and we would get through here. If it isn’t chocolate, we’d want this one to be strawberry, or whatever. We put :Flavor in there as well. There’s the finished procedure. I’m skeptical about Alex his estimate of time, 15 minutes sounds like a typical programmer’s underestimate. But this would not deserve Lauren’s comment, “It might be neat, but it’s dumb too.” So there, that’s bug out. It won’t say the dumb thing, Some chocolate ice cream, and some chocolate ice cream. But is the program done? Do spirals ever end?
In this segment I plant the seed of an idea that we’ll reap in Hurdles tape four. I call the idea, Names on Loan. The soil for this idea was prepared in the New Mindstorms tapes, when we talked about giving procedures inputs. I also prepared a problem in segment one of this tape. Lion, you remember, wanted to be called Seymour, and I’ve conceded, to the extent of calling the word Lion Seymour. But suppose that hedgehog said, me too? Easy enough to dub Hedgehog Seymour, but then Lion would have lost the name. Maybe a dangerous situation for Hedgehog. Lion will be mad. Logo has ways of dealing with this situation. Of course, not for pandering to toy animals, but because losing your name is a serious matter. Logo gets a lot of its power from its ability to protect its Logo things from losing their names.
For example, suppose I wanted to run the procedure you’ve written. This simple one stands in for your complex and elegant creation. The only relevant point here is that you’ve chosen Seymour as the name for the input. When this procedure is run, the title line tells it that it needs an input, and that it should name its input Seymour. In Greet, “Hedgehog, hedgehog is the input. It’s named Seymour, although there’s no explicit name here, there’s an implicit naming. Hedgehog is now the thing of Seymour, and that’s why, when Greet runs it will print, Hi, Hedgehog. Hedgehog is the thing of Seymour. Will this get us into trouble with Lion? No, it won’t. Because the naming that was done automatically here is only a loan. The name Seymour is loaned to the word hedgehog.
While Greet was running, Hedgehog is called Seymour. But when Greet reaches its end, the name is returned to its previous owner. Let’s see how this works on a computer screen. Before putting Lions, Hedgehogs and Greet on the screen, I’m going to put the issue of giving and lending names in the context of a previous naming. One that we did as a tool, so that we could change the color of the screen, without remembering which numbers corresponded to which colors. But then suppose after a while, seeking a name for this list, I chose “Green, forgetting about background colors. Then after another while, I forgot about that, and did SETBG :GREEN. But :GREEN now isn’t a number 2, it’s a list. I’ll get an error. SETBG doesn’t like a list as an input.
Another example. NAME “ME “SEYMOUR. PRINT :SEYMOUR. Me. NAME “LION “SEYMOUR. PRINT :SEYMOUR. Lion. What I want you to note is that this naming obliterates without a trace. This naming. If I was relying on preserving the effects of that in the computer, I’d be badly damaged by doing this. Now, since I did both namings, I should take responsibility. But where I don’t want to take responsibility is when I’m using your procedure. I don’t want to have to know its technical details in order to use it. And as a matter of fact, when we look at its technical details, we might see there’s reason for fear, because it uses the same name as I used to name Lion. It names Hedgehog, Seymour. But although Greet does an automatic naming, it also automatically invokes a protective device, a loan system.
It doesn’t actually give the name Seymour to Hedgehog, it lends the name Seymour to Hedgehog. And the term of the loan is the duration of the run of the procedure. When the procedure is finished, when it gets to End, the name Seymour reverts to its previous owner, so that the same instruction now produces another effect. This protective device, this loan system, means that I can use a procedure without having to fear that the way it names its inputs, will interfere with any namings that I happened to have set up for any other purpose. I cannot overstate the importance or the richness of this idea of names on loan. Maybe you understand it already pretty well, but you may still luck out as you work with it. You may yet experience a few more times that intellectual high that comes when you find a new [faceted 00:30:43] understanding of a concept … for that matter, of a person, you’ve known for a long time.