diff options
| author | elioat <elioat@tilde.institute> | 2023-08-23 07:52:19 -0400 |
|---|---|---|
| committer | elioat <elioat@tilde.institute> | 2023-08-23 07:52:19 -0400 |
| commit | 562a9a52d599d9a05f871404050968a5fd282640 (patch) | |
| tree | 7d3305c1252c043bfe246ccc7deff0056aa6b5ab /js/games/nluqo.github.io/~bh/v1ch2 | |
| parent | 5d012c6c011a9dedf7d0a098e456206244eb5a0f (diff) | |
| download | tour-562a9a52d599d9a05f871404050968a5fd282640.tar.gz | |
*
Diffstat (limited to 'js/games/nluqo.github.io/~bh/v1ch2')
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/annotated.gif | bin | 0 -> 1371 bytes | |||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/badparens.gif | bin | 0 -> 1037 bytes | |||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/blackbirds.gif | bin | 0 -> 1284 bytes | |||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/cheap-tree.gif | bin | 0 -> 1210 bytes | |||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/okparens.gif | bin | 0 -> 1120 bytes | |||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/proced.html | 1298 | ||||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/semantics.gif | bin | 0 -> 1258 bytes | |||
| -rw-r--r-- | js/games/nluqo.github.io/~bh/v1ch2/sixes.gif | bin | 0 -> 1254 bytes |
8 files changed, 1298 insertions, 0 deletions
diff --git a/js/games/nluqo.github.io/~bh/v1ch2/annotated.gif b/js/games/nluqo.github.io/~bh/v1ch2/annotated.gif new file mode 100644 index 0000000..f201653 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/annotated.gif Binary files differdiff --git a/js/games/nluqo.github.io/~bh/v1ch2/badparens.gif b/js/games/nluqo.github.io/~bh/v1ch2/badparens.gif new file mode 100644 index 0000000..a2f6e66 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/badparens.gif Binary files differdiff --git a/js/games/nluqo.github.io/~bh/v1ch2/blackbirds.gif b/js/games/nluqo.github.io/~bh/v1ch2/blackbirds.gif new file mode 100644 index 0000000..4efd961 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/blackbirds.gif Binary files differdiff --git a/js/games/nluqo.github.io/~bh/v1ch2/cheap-tree.gif b/js/games/nluqo.github.io/~bh/v1ch2/cheap-tree.gif new file mode 100644 index 0000000..c9a3f56 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/cheap-tree.gif Binary files differdiff --git a/js/games/nluqo.github.io/~bh/v1ch2/okparens.gif b/js/games/nluqo.github.io/~bh/v1ch2/okparens.gif new file mode 100644 index 0000000..d014eb3 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/okparens.gif Binary files differdiff --git a/js/games/nluqo.github.io/~bh/v1ch2/proced.html b/js/games/nluqo.github.io/~bh/v1ch2/proced.html new file mode 100644 index 0000000..07a3f98 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/proced.html @@ -0,0 +1,1298 @@ +<HTML> +<HEAD> +<TITLE>Computer Science Logo Style vol 1 ch 2: Procedures</TITLE> +</HEAD> +<BODY> +<CITE>Computer Science Logo Style</CITE> volume 1: +<CITE>Symbolic Computing</CITE> 2/e Copyright (C) 1997 MIT +<H1>Procedures</H1> + +<TABLE width="100%"><TR><TD> +<IMG SRC="../csls1.jpg" ALT="cover photo"> +<TD><TABLE> +<TR><TD align="right"><CITE><A HREF="http://www.cs.berkeley.edu/~bh/">Brian +Harvey</A><BR>University of California, Berkeley</CITE> +<TR><TD align="right"><BR> +<TR><TD align="right"><A HREF="../pdf/v1ch02.pdf">Download PDF version</A> +<TR><TD align="right"><A HREF="../v1-toc2.html">Back to Table of Contents</A> +<TR><TD align="right"><A HREF="../v1ch1/v1ch1.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="../v1ch3/v1ch3.html"><STRONG>NEXT</STRONG></A> +<TR><TD align="right"><A HREF="https://mitpress.mit.edu/books/computer-science-logo-style-second-edition-volume-1">MIT +Press web page for Computer Science Logo Style</A> +</TABLE></TABLE> + +<HR> + +<P>Logo is one of the most powerful programming languages around. +In order to take advantage of that power, you must understand +Logo's central ideas: <EM>procedures</EM> and <EM>evaluation.</EM> +It is with these ideas that our exploration of Logo programming begins. + +<P><H2>Procedures and Instructions</H2> + +<P> +In response to Logo's question-mark prompt, type this instruction: + +<P><PRE>print 17 +</PRE> + +<P>Logo will respond to this instruction by printing the number +17 and then printing another question mark, to indicate that it's +ready for another instruction: + +<P><PRE>? <U>print 17</U> +17 +</PRE> + +<P>(Remember, the <CODE><U>underlined</U></CODE> things are the ones <EM> +you</EM> should type; what's <CODE>not underlined</CODE> is what the computer prints.) + +<P>This instruction doesn't do much, but it's important to understand how it's +put together. The word <CODE>print</CODE> is the name of a <EM>procedure,</EM> +which is a piece of a computer program that has a particular specialized +task. The procedure named <CODE>print</CODE>, for example, has the task of printing +things on your screen. + +<P>If you have previously used some other programming language, you may +be accustomed to the idea of different <EM>statement types</EM> making +up the repertoire of the language. For example, BASIC has a <CODE>print</CODE> +statement, a <CODE>let</CODE> statement, an <CODE>input</CODE> statement, etc. Pascal +has an assignment +statement, an <CODE>if</CODE> statement, a <CODE>while</CODE> statement, etc. Each +kind of statement has its own <EM>syntax,</EM> that is, its own special +punctuation and organization. Logo is very different. It does not +have different kinds of instructions; <EM>everything</EM> in Logo is +done by the use of procedures. If Logo is your first programming +language, you don't have to worry about this. But for people with +previous experience in another language, it's a common source of misunderstanding. + +<P>When you first start up Logo, it "knows" about 200 procedures. These +initial procedures are called <EM>primitive</EM> procedures. Your task +as a Logo programmer is to add to Logo's repertoire by defining new +procedures of your own. You do this by putting together procedures that +already exist. We'll see how this is done later in this chapter. + +<P>The procedure <CODE>print</CODE>, although it has a specific task, doesn't always +do <EM>exactly</EM> the same thing; it can print anything you want, not +always the number 17. (You've seen several examples in Chapter 1.) +This may seem like an obvious point, but later you will see that the +<EM>flexibility</EM> of procedures is an important part of what makes +them so powerful. To control this flexibility, we need a way to tell +a procedure exactly what we want it to do. Therefore, each procedure +can accept a particular number of <EM>inputs.</EM> An input is a piece +of information. It can be a number, as in the example we're examining, +but there are many other kinds of information that Logo procedures +can handle. The procedure named <CODE>print</CODE> requires one input. Other +procedures will require different numbers of inputs; some don't require +any. + +<H2>Technical Terms</H2> + +<P>In ordinary conversation, words such as <EM>instruction</EM> and <EM> +procedure</EM> have pretty much the same meaning--they refer to any +process, recipe, or method for carrying out some task. That's not the +situation when we're talking about computer programming. Each of +these words has a specific technical meaning, and it's very important +for you to keep them straight in your head while you're reading this +chapter. (Soon we'll start using more words, such as <EM>command</EM> and +<EM>operation,</EM> which also have similar meanings in ordinary use but +very different meanings for us.) + +<P>An <EM>instruction</EM> is what you type to Logo to +tell it to do something. <CODE>Print 17</CODE> is an example of an +instruction. We're about to see some more complicated instructions, +made up of more pieces. An instruction has to contain enough +information to specify <EM>exactly</EM> what you want Logo to do. To +make an analogy with instructing human beings, "Read Chapter 2 of +this book" is an instruction, but "read" isn't one, because it +doesn't tell you what to read. + +<P>A <EM>procedure</EM> is like a recipe or a technique for carrying out a +certain kind of task. <CODE>Print</CODE> is the name of a procedure just as +"lemon meringue pie" is the name of a recipe. (The recipe itself, +as distinct from its name, is a bunch of instructions, such as "Preheat +the oven to 325 degrees.") A procedure contains information about how +to do something, but the procedure doesn't take action itself, just as +a recipe in a book can't bake a pie by itself. Someone has to carry +out the recipe. In the Logo world something has to <EM>invoke</EM> a +procedure. To "invoke" a procedure means to carry it out, to do +what the procedure says. Procedures are invoked by instructions. The +instruction you gave just now invoked the procedure named <CODE>print</CODE>. + +<P>If an instruction is made up of names of procedures, and if the procedures +invoked by the instruction are made up of more instructions, why doesn't the +computer get caught in a vicious circle, always finding more detailed +procedures to invoke and never actually doing anything? This question is a +lot like the one about dictionaries: When you look up the definition of a +word, all you find is more words. How do you know what <EM>those</EM> words +mean? For words in the dictionary this turns out to be a very profound and +difficult question. For Logo programming the answer is much simpler. In +the end, your instructions and the procedures they invoke must be defined in +terms of the primitive procedures. Those procedures are not made up of Logo +instructions. They're the things that Logo just knows how to do in the +first place. + +<P> +<H2>Evaluation</H2> + +<P>Now try this instruction: + +<P><PRE>print sum 2 3 +</PRE> + +<P>If everything is going according to plan, Logo didn't print +the words "<CODE>sum 2 3</CODE>"; it printed the number 5. The input to +<CODE>print</CODE> was the expression <CODE>sum 2 3</CODE>, but Logo <EM> +evaluated</EM> the input before passing it to the <CODE>print</CODE> procedure. +This means that Logo invoked the necessary procedures (in this case, +<CODE>sum</CODE>) to compute the value of the expression (5). + +<P>In this instruction the word <CODE>sum</CODE> is also the name of a procedure. +<CODE>Sum</CODE> requires two inputs. In this case we gave it the numbers 2 and +3 as inputs. Just as the task of procedure <CODE>print</CODE> is to print something, +the task of procedure <CODE>sum</CODE> is to add two numbers. It is the result +of this addition, the <EM>output</EM> from <CODE>sum</CODE>, that becomes the +<EM>input</EM> to <CODE>print</CODE>. + +<P>Don't confuse <EM>output</EM> with <EM>printing.</EM> In Logo the word +"output" is one of those technical terms I mentioned before. It +refers to a value that one procedure computes and hands on to another +procedure that needs an input. In this example <CODE>sum</CODE> outputs the +number 5 to <CODE>print</CODE>, but <CODE>print</CODE> doesn't output anything +to +another procedure. When <CODE>print</CODE> prints the 5, that's the end of +the story. There are no more procedures waiting for inputs. + +<P>See if you can figure out what this instruction will do before you +try it: + +<P><PRE>print sum 4 product 10 2 +</PRE> + +<P>Here are the steps Logo takes to evaluate the instruction: + + + + +<P><OL><LI>The first thing in the instruction is the name of the procedure +<CODE>print</CODE>. Logo knows that <CODE>print</CODE> requires one input, so it continues +reading the instruction line. + +<P><LI>The next thing Logo finds is the word <CODE>sum</CODE>. This, too, is the +name of a procedure. This tells Logo that the <EM>output</EM> from +<CODE>sum</CODE> will be the <EM>input</EM> to <CODE>print</CODE>. + +<P> +<LI>Logo knows that <CODE>sum</CODE> takes two inputs, so +<CODE>sum</CODE> can't be invoked until Logo finds <CODE>sum</CODE>'s inputs. + +<P><LI>The next thing in the instruction is the number 4, so that must be +the first input to <CODE>sum</CODE>. This input, too, must be evaluated. +Fortunately, a number simply evaluates to itself, so the value of this +input is 4. + +<P><LI>Logo still needs to find the second input to <CODE>sum</CODE>. The next thing +in the instruction is the word <CODE>product</CODE>. This is, again, the name +of a procedure. Logo must carry out that procedure to evaluate <CODE>sum</CODE>'s +second input. + +<P><LI>Logo knows that <CODE>product</CODE> requires two inputs. It must now look +for the first of those inputs. (Meanwhile, <CODE>print</CODE> and <CODE>sum</CODE> are both +"on hold" waiting for their inputs to be evaluated. <CODE>print</CODE> is waiting +for its single input; <CODE>sum</CODE>, which has found one input, is waiting for +its second.) The next thing on the line is the number 10. This number +evaluates to itself, so the first input to <CODE>product</CODE> is 10. + +<P><LI>Logo still needs another input for <CODE>product</CODE>, so it continues reading +the instruction. The next thing it finds is the number 2. This +number evaluates to itself, so the second input to <CODE>product</CODE> has the +value 2. + +<P><LI>Logo is now ready to invoke the procedure <CODE>product</CODE>, with inputs +10 and 2. The output from <CODE>product</CODE> is 10 times 2, or 20. + +<P><LI>This output, 20, is the value of the second input to <CODE>sum</CODE>. Logo +is now ready to invoke <CODE>sum</CODE>, with inputs 4 and 20. The output +from <CODE>sum</CODE> is 24. + +<P><LI>The output from <CODE>sum</CODE>, 24, is the input to <CODE>print</CODE>. Logo is now +ready to invoke <CODE>print</CODE>, which prints 24. (You were only waiting +for this moment to arise.) + +<P></OL> + + +<P>That's a lot of talking about a pretty simple instruction! I promise +not to do it again in quite so much detail. It's important, though, +to be able to call upon your understanding of these details to figure +out more complicated situations later. Using the output from one procedure +as an input to another procedure is called <EM>composition +of functions.</EM> + +<P>Some people find it helpful to look at a pictorial form of this analysis. +We can represent each procedure as a kind of tank, with input hoppers +on top and perhaps an output pipe at the bottom. (This organization +makes sense because gravity will pull the information downward.) +For example: + +<P><CENTER><IMG SRC="https://people.eecs.berkeley.edu/~bh/v1ch2/machines.gif" ALT="figure: machines"></CENTER> + +<P><CODE>Print</CODE> has one input, which is represented by the hopper above +the tank. It doesn't have an output, so there is no pipe coming out +the bottom. <CODE>Sum</CODE> has two inputs, shown at the top, and an output, +shown at the bottom. + +<P>We can put these parts together to form a kind +of "plumbing diagram" +of the instruction: + +<P><CENTER><IMG SRC="blackbirds.gif" ALT="figure: blackbirds"></CENTER> + +<P>In that diagram the output pipes from one procedure are connected +to the input hoppers of another. Every pipe must be connected to something. +The inputs that are explicitly given as numbers in the instruction +are shown with arrows pointing into the hoppers. + +<P>You can annotate the diagram by indicating the actual information +that flows through each pipe. Here's how that would look for this +instruction: + +<P><CENTER><IMG SRC="annotated.gif" ALT="figure: annotated"></CENTER> + +<P>By the way, I've introduced the procedures <CODE>print</CODE>, <CODE> +sum</CODE>, and <CODE>product</CODE> so casually that you might think it's a law of +nature that every programming language must have procedures with these +names. Actually the details of Logo's repertoire of primitive +procedures are quite arbitrary. It would be hard to avoid having a way +to add numbers, but it might have been named <CODE>plus</CODE> or <CODE>add</CODE> +instead of <CODE>sum</CODE>. For some primitives there are additional +arbitrary details; for noncommutative +operations such as <CODE>remainder</CODE>, for example, the +rule about which input comes first was an +arbitrary choice for Logo's designers. (» Experiment with <CODE> +remainder</CODE> and see if you can describe it well enough that someone +else can use it without needing to experiment.) I am making a point of +the arbitrary nature of these details because people who are learning +to program sometimes think they're doing badly if they don't <EM> +figure out</EM> how a primitive procedure works in advance. But these +rules aren't things you work out; they're things someone has to tell +you, like the capital of Kansas. + +<P> +<H2>Error Messages</H2> + +<P>We've observed that Logo knows in advance how many inputs a particular +procedure needs. (<CODE>Print</CODE> needs one; <CODE>sum</CODE> and <CODE>product</CODE> +each need two.) What if you give a procedure the wrong number of +inputs? Try this: + +<P><PRE>print +</PRE> + +<P>(That is, the word <CODE>print</CODE> as an instruction all by itself, +with no input.) You should see something like this: + +<P><PRE>? <U>print</U> +Not enough inputs to print +</PRE> + +<P>This gentle complaint from Logo tells you two things. First, +it indicates the general <EM>kind</EM> of thing that went wrong (not +enough inputs to some procedure). Second, it names the <EM>particular</EM> +procedure that complained (<CODE>print</CODE>). In this case it was pretty obvious +which procedure was involved, since we only used one procedure. But +try this: + +<P><PRE>? <U>print remainder product 4 5</U> +Not enough inputs to remainder +</PRE> + +<P>In this case Logo's message is helpful in pinpointing the +fact that it was <CODE>remainder</CODE>, not <CODE>print</CODE> or <CODE>product</CODE>, +that lacked an input. + +<P>The reason I'm beating this error message to death is that one of +the most common mistakes made by beginning programmers is to ignore +what an error message says. Some people get very upset at seeing +this kind of message and just give up without trying to figure out +the problem. Other people make the opposite mistake, breezing past +the message without taking advantage of the detailed help it offers. +Some smart people at M.I.T. put a lot of effort into designing Logo's +error messages, so please pay attention to them. + +<P>What if you give a procedure too many inputs? Try this: + +<P><PRE>? <U>print 2 3</U> +2 +You don't say what to do with 3 +</PRE> + +<P>(The exact text of the message, by the way, may be slightly +different in some versions of Logo.) What happened here is that Logo +carried out the instruction <CODE>print 2</CODE>, and then found the extra +number <CODE>3</CODE> on the line. It would have been okay if we'd done +something with the 3: + +<P><PRE>? <U>print 2 print 3</U> +2 +3 +</PRE> + +<P>It's okay to have more than one instruction on the same +line, as long as they are complete instructions. + +<P><H2>Commands and Operations</H2> + +<P>What's a "complete instruction"? Before I can answer that question, +you have to understand that in Logo there are two kinds of procedures: +commands and operations. + +<P>An <EM>operation</EM> is a procedure that computes a value and outputs +it. <CODE>Sum</CODE> and <CODE>product</CODE> are operations, for example. + +<P>A <EM>command</EM> is a procedure that does <EM>not</EM> output a value +but instead has some <EM>effect</EM> such as +printing something on the screen, +moving a turtle, or making a sound. <CODE>Print</CODE>, then, is a command. Some +commands have effects that are not apparent on the outside but instead +change something inside the computer that might become important +later in the program. + +<P>A complete instruction consists of the name of a command, followed by +as many expressions as necessary to provide its inputs. An <EM> +expression</EM> is something like <CODE>sum 3 2</CODE> or <CODE>17</CODE>. +Operations are used to construct expressions. More formally, an +expression is one of two things: either an explicitly provided value +such as a number, or else the name of an operation, followed by as many +expressions as necessary to provide its inputs. For example, the +expression <CODE>sum 3 2</CODE> consists of the operation name <CODE>sum</CODE> +followed by two expressions, the number <CODE>3</CODE> and the number <CODE> +2</CODE>. Numbers are the only values we've seen how to provide +explicitly, but that's about to change. + +<P><H2>Words and Lists</H2> + +<P>So far, our examples have been about numbers and arithmetic. Many +people think that computers just do arithmetic, but actually it's +much more interesting to use computers with other kinds of information. +You've seen examples of text processing in Chapter 1, but this time +we're going to do it <EM>carefully!</EM> + +<P>Suppose you want Logo to print the word +<CODE>Hello</CODE>. You might try this: + +<P><PRE>? <U>print Hello</U> +I don't know how to Hello +</PRE> + +<P>Logo interpreted the word <CODE>Hello</CODE> as the name of a procedure, +just as in the examples with <CODE>print sum</CODE> earlier. The error message +means that there is no procedure named <CODE>hello</CODE> in Logo's repertoire. + +<P> +When Logo is evaluating instructions, it always interprets unadorned +words such as <CODE>print</CODE> or <CODE>sum</CODE> or <CODE>hello</CODE> as names of +procedures. In order to convince Logo to treat a word simply as +itself, you must type a quotation mark (<CODE>"</CODE>) in front of it: + + +<P><PRE>? <U>print "Hello</U> +Hello +</PRE> + +<P> +Here is why the quotation mark is used for this purpose +in Logo: In computer science, to <EM>quote</EM> something means <EM> +to prevent it from being evaluated.</EM> (Another way to say the same +thing is that <EM>the thing evaluates to itself</EM> or that its value +<EM>after</EM> evaluation is the same as what it is <EM>before</EM> evaluation.) +For example, we have already seen that in Logo, numbers +are automatically +quoted. (It doesn't hurt to use the quotation mark with numbers, +however. + +<P><PRE>? <U>print sum "2 "3</U> +5 +</PRE> + +<P>Logo is perfectly happy to add the quote-marked numbers.) + + +<P>(People who have programmed in some other language should note that +quotation marks are not used in pairs in Logo. This is not just an +arbitrary syntactic foible; it reflects the fact that a Logo <EM> +word</EM> is a different idea from what would be called +a <EM>character string</EM> in other +languages. I urge you not only to program in Logo +but even to think in Logo terminology.) + +<P>What if you want to print more than one word? You can combine several +words to form a <EM>list.</EM> The easiest way to do this is to enclose +the words in square brackets, which tells Logo to quote the list. +That is, a list in brackets evaluates to the list itself: + +<P><PRE>? <U>print [How are you?]</U> +How are you? +</PRE> + +<P>(If square brackets quote a list, what does it mean to evaluate +a list? Well, every instruction line you type to Logo is actually +a list, which is evaluated by invoking the procedures it names. Most +of the time you don't have to remember that an instruction is a list, +but that fact will become very useful later on.) + +<P>The list in the example above contains three <EM>members.</EM> In this +example each member is a word. For example, the first member is the word <CODE> +How</CODE>. But the members of a list aren't required to be words; they can +also be lists. The fact that a list can have another list as a member +makes lists very flexible as a way of grouping information. For +example, the list + +<P><PRE>[[cherry vanilla] mango [root beer swirl]] +</PRE> + +<P>contains three members. The first and third members are +themselves lists, while the second member is the word <CODE>mango</CODE>. A +list like this can be represented using a <EM>tree diagram:</EM> + +<P> +<P><CENTER><IMG SRC="https://people.eecs.berkeley.edu/~bh/v1ch2/icecream.gif" ALT="figure: icecream"></CENTER> + +<P>This diagram has the name "tree" because it resembles an +upside-down tree, with a trunk at the top and branches extending +downward. Often a tree diagram is drawn with only the <EM>leaves</EM> +labeled--the words that make up the smallest sublists: + +<P><CENTER><IMG SRC="cheap-tree.gif" ALT="figure: cheap-tree"></CENTER> + + +<P>Keep in mind that the square brackets in Logo serve two purposes at +once: they <EM>delimit</EM> a list--that is, they show where the list +begins and ends--and they also <EM>quote</EM> the list, so that Logo's +evaluator interprets the list as representing itself and not as requesting +the invocation of procedures. The brackets surround the list; they +are not <EM>part of</EM> the list. (Similarly, the quotation mark that +indicates a quoted word is not part of the word.) + +<P>Words and lists are the two kinds of information that Logo can process. +(Numbers are a special case of words.) The name I'll use for "either +a word or a list" is a <EM>datum.</EM><SUP>*</SUP> A list of words, such as +<CODE>[How are you?]</CODE>, is called a <EM>sentence</EM> +or a <EM>flat list.</EM> (It's called "flat" because the tree +diagram only has one level, not counting the "root" at the top.) +The name "sentence" is meant to suggest that flat lists are often, +although not always, used to represent English sentences. A sentence +is a special kind of list, just as a number is a special kind of word. +We'll see other kinds of lists later. + +<P><SMALL><BLOCKQUOTE><SMALL><SUP>*</SUP>Later we'll use a +third kind of datum, called an "array."</SMALL></BLOCKQUOTE></SMALL><P> +<H2>How to Describe a Procedure</H2> + +<P>My high school U.S. history teacher was very fussy about what he considered +the proper way to color in outline maps. He would make us do them +over if we used colors or shading techniques he didn't like. We humored +him because he was a very good teacher in other ways; for example, +he gave us original historical documents to read instead of boring +textbooks. + +<P>I hope you will humor me when I tell you that there is a right way and a +wrong way to talk about procedures. If I were teaching you in person, I'd +be very understanding about mistakes in your <EM>programs,</EM> but I'd hit +you over the head (gently, of course) if you were sloppy about your <EM> +descriptions.</EM> + +<P>Here is an example of the wrong way: "<CODE>Sum</CODE> adds up two numbers." +It's not that this description isn't true but that it's inadequate. +It leaves out too much. + +<P>Here is an example of the right way: "<CODE>Sum</CODE> is an operation. +It has two inputs. Both inputs must be numbers. The output from +<CODE>sum</CODE> is a number, the result of adding the two inputs." + +<P>Here are the ingredients in the right way: + +<P> + + +<OL><LI> Command or operation? + +<P><LI> How many inputs? + +<P><LI> What <EM>type</EM> of datum must each input be? + +<P><LI> If the procedure is an operation, what is its <EM>output?</EM> If +a command, what is its <EM>effect?</EM> + +<P></OL> + + +<P>Another example: "The command <CODE>print</CODE> has one input. The input +can be any datum. The effect of <CODE>print</CODE> is to print the input datum +on the screen." + +<P><H2>Manipulating Words and Lists</H2> + +<P>Logo provides several primitive operations for taking data apart +and putting data together. Words come apart into <EM> +characters,</EM> +such as letters or digits or punctuation marks. (A character is not +a third kind of datum. It's just a word that happens to be one character +long.) Lists come apart into whatever data are the <EM>members</EM> +of the list. A sentence, which is a list of words, comes apart into +words. + +<P><CODE>First</CODE> is an operation that takes one input. The input can be any +nonempty datum. (In a moment you'll see what an empty datum is.) +The output from <CODE>first</CODE> is the first member of the input if the input +is a list, or the first character if the input is a word. Try these +examples: + +<P><PRE>? <U>print first "Hello</U> +H +? <U>print first [How are you?]</U> +How +</PRE> + +<P><CODE>Butfirst</CODE> is also an operation that takes one input. The input can +be any nonempty datum. The output from <CODE>butfirst</CODE> is a list containing +all but the first member of the input if the input is a list, or +a word containing all but the first character of the input if it's +a word: + +<P><PRE>? <U>print butfirst "Hello</U> +ello +? <U>print butfirst [How are you?]</U> +are you? +</PRE> + +<P>Notice that the <CODE>first</CODE> of a list can be a word, but the <CODE>butfirst</CODE> of +any datum is always another datum of the same type. Also notice +what happens when you take the <CODE>butfirst</CODE> of a datum with only one +thing in it: + +<P><PRE>? <U>print butfirst "A</U> + +? <U>print butfirst [Hello]</U> + +? +</PRE> + +<P>In each case Logo printed a blank line. In the first case +that blank line represents an empty word, a word +with no characters +in it. The second blank line represents an empty list, a list +with no members. You can indicate the empty word in an instruction +by using a quotation mark with a space (or the RETURN key to end the +instruction) after it. To indicate an empty list, use brackets with +nothing inside them: + +<P><PRE>? <U>print " print []</U> + + +? +</PRE> + +<P>Do you understand why it doesn't make sense to use the empty +word or the empty list as input to <CODE>first</CODE> or <CODE>butfirst</CODE>? Try it and +see what happens. + +<P>You should also notice that the list <CODE>[Hello]</CODE> is not the same as the +word <CODE>"Hello</CODE>. They look the same when you print them, but they +act differently when you take their <CODE>first</CODE> or <CODE>butfirst</CODE>. + +<P>There are also primitive operations <CODE>last</CODE> and <CODE>butlast</CODE>. I'm +sure you'll have no trouble guessing what they do. Try them out, then +practice describing them properly. + +<P>This is probably a good place to mention that there are <EM> +abbreviations</EM> for some Logo primitive procedures. For +example, <CODE>bf</CODE> is an abbreviation for <CODE>butfirst</CODE>. <CODE>Pr</CODE> is an +abbreviation for <CODE>print</CODE>. There isn't any abbreviation for <CODE> +first</CODE>. + +<P>If you want to extract a piece of a word or list that isn't at the beginning +or end, you can use the more general operation <CODE>item</CODE> with two +inputs: a positive integer to indicate which member to select, and a word +or list. For example: + +<P><PRE>? <U>print item 3 "Yesterday</U> +s +? <U>print item 2 [Good Day Sunshine]</U> +Day +</PRE> + +<P><CODE>First</CODE>, <CODE>last</CODE>, <CODE>butfirst</CODE>, <CODE>butlast</CODE>, and <CODE>item</CODE> are +taking-apart operations, or <EM>selectors.</EM> Logo also provides +putting-together operations, or <EM>constructors.</EM> + +<P><CODE>Sentence</CODE> is a constructor. It takes two inputs, which can be any +data at all. Its output is always a list. + +<P>Describing the output from <CODE>sentence</CODE> is a little tricky because the +same procedure serves two different purposes. The first purpose is the one +suggested by its name: constructing sentences. If you use only words and +sentences (flat lists) as inputs, then the output from <CODE>sentence</CODE> is a +sentence concatenating (stringing together) the words contained in the +inputs. Here are some examples: + +<P><PRE>? <U>print sentence "hello "goodbye</U> +hello goodbye +? <U>print sentence [this is] [a test]</U> +this is a test +? <U>print sentence "this [is one too]</U> +this is one too +? <U>print sentence [] [list of words]</U> +list of words +</PRE> + +<P>On the other hand, <CODE>sentence</CODE> can also be used to append two +lists (flat or not). With lists as inputs, the output from <CODE>sentence</CODE> +is a list in which the <EM>members</EM> of the first input and the <EM> +members</EM> of the second input are concatenated: + +<P><PRE>? <U>print sentence [[list 1a] [list 1b]] [[list 2a] [list 2b]]</U> +[list 1a] [list 1b] [list 2a] [list 2b] +? <U>print sentence [flat list] [[not flat] [list]]</U> +flat list [not flat] [list] +</PRE> + +<P>In the second example the output is a list with four +members: two words and two lists. + +<P>Using a word as input to <CODE>sentence</CODE> is equivalent to using a list with +that word as its single member. <CODE>Sentence</CODE> is the only primitive +operation that treats words the same +as single-word lists; you've seen from the earlier examples that <CODE>first</CODE> +and <CODE>butfirst</CODE> treat the word <CODE>hello</CODE> and the list <CODE>[hello]</CODE> +differently. + +<P>Another constructor for lists is <CODE>list</CODE>. Its inputs can be any data; +its output is a list whose members are the inputs--not the members of the +inputs, as for <CODE>sentence</CODE>. + +<P><PRE>? <U>print list [this is] [a test]</U> +[this is] [a test] +? <U>print list "this [is one too]</U> +this [is one too] +? <U>print list [] [list of words]</U> +[] [list of words] +</PRE> + +<P><CODE>Word</CODE> is an operation that takes two inputs. Both inputs must be words. +(They may be the empty word.) The output from <CODE>word</CODE> is a word formed +by concatenating the characters in the input +words: + +<P><PRE>? <U>print word "hello "goodbye</U> +hellogoodbye +? <U>print word "now "here</U> +nowhere +? <U>print word "this [is a test]</U> +word doesn't like [is a test] as input +</PRE> + +<P>Selectors and constructors can be composed, in the same way we composed <CODE> +sum</CODE> and <CODE>product</CODE> earlier. See if you can work out what this example +will do before you try it with the computer:<SUP>*</SUP> + +<P><SMALL><BLOCKQUOTE><SMALL><SUP>*</SUP>The tilde (<CODE>~</CODE>) at +the end of the first line is the notation used by Berkeley Logo to indicate +that this and the following line should be understood as a single, long +instruction line. It's somewhat analogous to the way a hyphen (-) is used +in English text when a single word must be split between two lines. +Berkeley Logo will also continue an instruction to the next line if a line +ends inside parentheses or brackets, so another way to indicate a long +instruction line is to enclose the entire instruction in parentheses, like +this: + +<P><PRE>(print word word last "awful first butfirst "computer ~ + first [go to the store, please.]) +</PRE> + +<P>Other Logo dialects have other rules for line continuation. +(In some dialects everything you type is automatically taken as one big +line, so you don't have to think about this.) In the book, I'll indent +continuation lines, as above, to make it quite clear that they are meant +to be part of the same instruction as the line above. But Logo doesn't pay +attention to the indentation.</SMALL></BLOCKQUOTE></SMALL><P><PRE>print word word last "awful first butfirst "computer + first [go to the store, please.] +</PRE> + +<P>Here is how I'd analyze it. + + + +The input to <CODE>print</CODE> is the output from <CODE>word</CODE>. + +<P>The first input to <CODE>word</CODE> is the output from <CODE>word</CODE>. + +<P>The first input to (the second) <CODE>word</CODE> is the output from <CODE>last</CODE>. + +<P>The input to <CODE>last</CODE> is the quoted word <CODE>awful</CODE>. + +<P>The output from <CODE>last</CODE> is the word <CODE>l</CODE>, which becomes the first input +to the second <CODE>word</CODE>. + +<P>The second input to the second <CODE>word</CODE> is the output from <CODE>first</CODE>. + +<P>The input to <CODE>first</CODE> is the output from <CODE>butfirst</CODE>. + +<P>The input to <CODE>butfirst</CODE> is the quoted word <CODE>computer</CODE>. + +<P>The output from <CODE>butfirst</CODE> is the word <CODE>omputer</CODE>, which +becomes the input to <CODE>first</CODE>. + +<P>The output from <CODE>first</CODE> is the word <CODE>o</CODE>, which becomes the +second input to the second <CODE>word</CODE>. + +<P>The output from the second <CODE>word</CODE> is the word <CODE>lo</CODE>, which becomes the +first input to the first <CODE>word</CODE>. + +<P>The second input to (the first) <CODE>word</CODE> is the output from (the second) +<CODE>first</CODE>. + +<P>The input to <CODE>first</CODE> is the sentence <CODE>[go to the store, please.]</CODE>. + +<P>The output from <CODE>first</CODE> is the word <CODE>go</CODE>, which becomes the +second input to the first <CODE>word</CODE>. + +<P>The output from <CODE>word</CODE> is the word <CODE>logo</CODE>, which becomes the input to +<CODE>print</CODE>. + +<P>Finally, <CODE>print</CODE> prints the word <CODE>logo</CODE>. + +<P> + + +<P>And here is the plumbing diagram: + +<P><CENTER><IMG SRC="https://people.eecs.berkeley.edu/~bh/v1ch2/logoplumb.gif" ALT="figure: logoplumb"></CENTER> + +<P>»If you made it through that, you should find it easy to predict what +these instructions will do: + +<P><PRE>print butlast "tricky +print butlast [tricky] +print se bl "farm bl bl bl "output +print first butfirst "hello +print first butfirst [abc def ghi] +(print word bl "hard word bl bl first [very hard] + last first [extremely hard]) +</PRE> + +<P>Remember that numbers are words, so you can combine arithmetic operations +with these word and list operations: + +<P><PRE>? <U>print word sum 2 3 product 2 3</U> +56 +? <U>print sum word 2 3 product 2 3</U> +29 +? <U>print sentence sum 2 3 word 2 3</U> +5 23 +</PRE> + +<P><CODE>Count</CODE> is an operation that takes one input. The input can be any +datum. The output from <CODE>count</CODE> is a number, indicating the length +of the input. If the input is a word, the output is the number of +characters in the word. If the input is a list, the output is the +number of members in the list. + +<P><PRE>? <U>print count "hello</U> +5 +? <U>print count [hello]</U> +1 +? <U>print count "</U> +0 +? <U>print count []</U> +0 +? <U>print word count "hello count "goodbye</U> +57 +? <U>print sum count "hello count "goodbye</U> +12 +</PRE> + +<P><H2>Print and Show</H2> + +<P>Because lists are often used to represent English sentences in +conversational programs like the <CODE>hi</CODE> procedure of Chapter 1, +<CODE>print</CODE> prints only the members of a list, without enclosing +brackets. This behavior could be confusing if a list contains +only one member: + +<P><PRE>? <U>print [aardvark]</U> +aardvark +? <U>print "aardvark</U> +aardvark +</PRE> + +<P>There is no visible difference between a word and a +one-word list. But the two values are actually quite different, +as we can see if we use them as inputs to <CODE>first</CODE>: + +<P><PRE>? <U>print first [aardvark]</U> +aardvark +? <U>print first "aardvark</U> +a +</PRE> + +<P>The <CODE>first</CODE> of a sentence is its first word, even if +it has only one word, but the <CODE>first</CODE> of a word is its first +letter. + +<P>To help distinguish words from lists, Logo has another printing +command called <CODE>show</CODE> that displays brackets around lists: + +<P><PRE>? <U>show [aardvark]</U> +[aardvark] +? <U>show "aardvark</U> +aardvark +? <U>show sentence [this is] [an example]</U> +[this is an example] +? <U>show list [this is] [an example]</U> +[[this is] [an example]] +</PRE> + +<P>Use <CODE>print</CODE> if your program wants to carry on a +conversation with the user in English. Use <CODE>show</CODE> if you are +using lists to represent some structure other than a sentence. + +<P><H2>Order of Evaluation</H2> + +<P>You may hear people say something like this: "Logo evaluates +from right to left." What they mean is that in an instruction such as + +<P><PRE>print first butfirst butfirst [print the third word] +</PRE> + +<P>Logo first evaluates + +<P><PRE>butfirst [print the third word] +</PRE> + +<P>and next evaluates + +<P><PRE>butfirst [the third word] +</PRE> + +<P>and then + +<P><PRE>first [third word] +</PRE> + +<P>and finally + +<P><PRE>print "third +</PRE> + +<P> +In other words, the procedures named toward the right end +of the instruction line must be invoked <EM>before</EM> Logo can know +the appropriate input values for the procedures farther to the left. + +<P>This right-to-left idea can be a useful way of helping you understand +evaluation in Logo. But you should realize that it's not quite true. +It only works out that way if the instruction line contains only one +instruction and each procedure used in that instruction takes only +one input. If you look back at one of the examples in which two-input +procedures such as <CODE>word</CODE> or <CODE>sum</CODE> are used, you'll see that Logo really +does read the instruction line from left to right. And if there are +two instructions on the same line, the one on the left is evaluated +first. + +<P>The reason for the seeming right-to-left evaluation is that Logo can't +<EM>finish</EM> evaluating a procedure invocation until it has collected +and evaluated the inputs to the procedure. But Logo <EM>starts</EM> +evaluating an instruction line by looking at the first word on the +line. In the example just above, the evaluation of <CODE>first</CODE> and +<CODE>butfirst</CODE> is <EM>part of</EM> the evaluation of <CODE>print</CODE>. + +<P><H2>Special Forms of Evaluation</H2> + +<P>So far, the evaluation process +has been very uniform. Logo looks at the first word of an instruction +and interprets that word as the name of a procedure. Logo knows how +many inputs each procedure requires. It then evaluates as many expressions +as necessary to assign values to those inputs. The expressions are +evaluated the same way: Logo looks at the first word... and so on. + +<P>Although this evaluation process is perfectly general, Logo also provides +a couple of special forms of evaluation to make certain things easier +to type. (The computer science terminology for such a special case +is a "kludge." The letter "u" in this word is pronounced as +in "rude," not as in "sludge.") + +<P>One special case is that Logo provides <EM>infix arithmetic</EM> as well +as the <EM>prefix arithmetic</EM> we've used so far. That is, you can +say + +<P><PRE>print 2+3 +</PRE> + +<P>instead of + +<P><PRE>print sum 2 3 +</PRE> + +<P>When you use infix operations, the usual rules of precedence apply: +multiplications and divisions are done before additions and +subtractions unless you use parentheses. In other words, <CODE>2+3*4</CODE> +(the asterisk represents multiplication) means <CODE>2+(3*4)</CODE>, while +<CODE>2*3+4</CODE> means <CODE>(2*3)+4</CODE>. You should take note that this issue +of precedence doesn't arise when prefix operations are used. + +<P>»For example, look at these expressions: + +<P><PRE>sum 2 product 3 4 +product sum 2 3 4 +sum product 2 3 4 +product 2 sum 3 4 +</PRE> + +<P>Each of these indicates precisely what order of operations +is desired. The first, for example, is equivalent to <CODE>2+3*4</CODE>. +Try converting the others to infix form. Which ones require +parentheses? + +<P>The second special form of evaluation is that certain primitive procedures +can be given extra inputs, or fewer inputs than usual, by using +parentheses around the procedure name and all its inputs. Here are +some examples: + +<P><PRE>? <U>print sum 2 3 4</U> +5 +You don't say what to do with 4 +? <U>print (sum 2 3 4)</U> +9 +? <U>show (list "one)</U> +[one] +? <U>show (list)</U> +[] +</PRE> + +<P><CODE>Sum</CODE>, <CODE>product</CODE>, <CODE>word</CODE>, <CODE>list</CODE>, +<CODE>sentence</CODE>, and <CODE>print</CODE> can be used with any number of inputs. + +<P>By the way, it is always permitted to enclose a procedure name and its +inputs (the correct number of them!) in parentheses, even when it's not +necessary, to make the instruction more readable. One of the earlier +illustrations, for example, might be easier to read in this form: + +<P><PRE>print word (word (last "awful) (first butfirst "computer)) ~ + (first [go to the store, please.]) +</PRE> + +<P>Notice that Logo's placement of parentheses is different from the +function notation used in algebra. In algebra you say <EM>f</EM>(<EM>x</EM>). In +Logo you would express the same idea as <CODE>(f x)</CODE>. + +<P><H2>Writing Your Own Procedures</H2> + +<P> + +With these tools, you are ready to begin writing new procedures. +Type this: + +<P><PRE>to hello +</PRE> + +<P><CODE>To</CODE> is a command, but it's a very special one. It's the +only one that does not evaluate its inputs. Remember earlier when +we said + +<P><PRE>print Hello +</PRE> + +<P>and Logo complained that it didn't know how to <CODE>Hello</CODE>? +Well, <CODE>to</CODE> doesn't make that kind of complaint. Instead it +prepares to have you <EM>teach it how</EM> <CODE>to hello</CODE>. (That's why <CODE> +to</CODE> is called <CODE>to</CODE>!) What you should see on the screen is +something like this: + +<P><PRE>? <U>to hello</U> +> +</PRE> + +<P>Instead of a question mark, Logo has printed a greater-than +symbol as the prompt. This special prompt warns you that whatever +instructions you type won't be carried out immediately, as usual. +Instead Logo remembers what you type as part of the procedure named +<CODE>hello</CODE>. Continue like this: + +<P><PRE>> <U>print "Hello</U> +> <U>print [This is Logo speaking.]</U> +> <U>print [What's new?]</U> +> <U>end</U> +? +</PRE> + +<P>The word <CODE>end</CODE> isn't the name of a procedure. It's a +special signal to Logo that you're finished defining the procedure <CODE> +hello</CODE>.<SUP>*</SUP> + +<P><SMALL><BLOCKQUOTE><SMALL><SUP>*</SUP>Why can't we simply think of <CODE>end</CODE> as the name of a +procedure, just as <CODE>print</CODE> is? This is a minor point, but one that you +can use to test your understanding of what's going on while you are defining +a procedure. When you see the greater-than +prompt, Logo <EM>does not evaluate</EM> the lines you type. It simply +remembers those lines as part of the procedure you're defining. If <CODE> +end</CODE> were a procedure, it wouldn't be evaluated right away, just as those +<CODE>print</CODE> instructions aren't evaluated right away. It, too, would be +remembered as part of the definition of <CODE>hello</CODE>. Instead, typing +<CODE>end</CODE> has an <EM>immediate</EM> effect: It ends the procedure definition +and returns to the question-mark prompt that allows interactive evaluation.</SMALL></BLOCKQUOTE></SMALL><P>Now you can try out your new procedure: + +<P><PRE>? <U>hello</U> +Hello +This is Logo speaking. +What's new? +</PRE> + +<P>You can also examine the procedure itself by asking Logo +to print it out. The command <CODE>po</CODE> (for Print Out) takes one input, +a word or a list. The input is either the name of a procedure (if +a word) or a list of names of procedures. The effect of <CODE>po</CODE> is to +print out the definition(s) of the procedure(s) named by the input. +Here is an example: + +<P><PRE>? <U>po "hello</U> +to hello +print "Hello +print [This is Logo speaking.] +print [What's new?] +end +? +</PRE> + +<P>Unlike <CODE>to</CODE>, but like all other Logo procedures, <CODE> +po</CODE> <EM>does</EM> evaluate its input. That's why the word <CODE>hello</CODE> +must be quoted in this example. + +<P>In a procedure definition the line starting <CODE>to</CODE> is called the <EM> +title line.</EM> The lines containing instructions are, naturally, called +<EM>instruction lines.</EM> We won't have many occasions to talk about +the line containing only the word <CODE>end</CODE>, but just in case, we'll call +it the <EM>end line.</EM> + +<P>The command <CODE>pops</CODE> (for Print Out ProcedureS) takes no inputs. Its +effect is to print out the definitions of all the procedures you've +defined. The command <CODE>pots</CODE> (for Print Out TitleS) also takes no inputs +and prints out only the title lines of all the procedures you've defined. + +<P>Some writers and teachers reserve the word "procedure" to refer only +to ones you write yourself, such as <CODE>hello</CODE>. They use the word +"primitive" as a noun, to mean things like <CODE>print</CODE> and <CODE> +butfirst</CODE>. They say things like "Logo instructions are made up +of procedures and primitives." This is a big mistake. The procedures +you write are <EM>just like</EM> the procedures Logo happens to know +about in the first place. It's just that somebody else wrote the +primitive procedures. But you use your own procedures in exactly the +same way that you use primitive procedures: you type the name of the +procedure and Logo evaluates that name by invoking the procedure. +It's okay to say "<CODE>Last</CODE> is a primitive" as an abbreviation for +"<CODE>Last</CODE> is a primitive procedure," as long as you know what +you're talking about. + +<P>»Try defining more procedures. You'll find that you don't have quite +enough tools yet to make your procedures very interesting; the main +problem is that yours don't take inputs, so they do exactly the same +thing every time you use them. We'll solve that problem in the next +chapter. + +<P><H2>Editing Your Procedures</H2> + +<P>As you may remember from earlier experiences, Logo includes +an <EM>editor,</EM> a program that allows you to make corrections to +a procedure you've defined. You can also use the editor to write +procedure definitions in the first place. The editor works slightly +differently in each version of Logo, so you should consult the manuals +for your own computer (or Appendix A, for Berkeley Logo) to review the details. + +<P>By the way, when you're learning about the <CODE>edit</CODE> command, don't forget +that it can accept a list of procedure names as input, not only a +single word. By listing several procedures in the input to <CODE>edit</CODE>, +you can have them all visible at once while you're editing, +and you can copy instructions from one to another. This is a powerful +capability of the Logo editor, which beginners often neglect. + +<P>Once you've gotten familiar with the Logo editor, you'll probably find +yourself wanting to use it all the time, and you'll rarely choose to +define a procedure by invoking <CODE>to</CODE> directly. (Don't get +confused about that last sentence; of course you type <CODE>to</CODE> when +you're using the editor, but you don't type it as a command to the +Logo interpreter in response to a question mark prompt.) The editor +makes it much easier to correct typing mistakes. Nevertheless, if you +need to define a short procedure in the middle of doing something else, you +may occasionally find it simpler to use <CODE>to</CODE> rather than wait for an +editor to start up. + +<P><H2>Syntax and Semantics</H2> + +<P>Except for the special case of <CODE>to</CODE>, all Logo instructions follow the +same rules about the meaning of punctuation and about which subexpression +provides an input to which procedure call. These are called <EM> +syntax</EM> rules. The rules pay no attention to what any particular +procedure means, or what inputs might or might not be sensible for that +procedure; those aspects of a program are called its <EM> +semantics,</EM> which is a fancy word for "meaning." You might say +that Logo's plumber, the part of Logo that hooks up the plumbing diagrams, +doesn't know anything about semantics. So, for example, if you make a +mistake like + +<P><PRE>print item [john paul george ringo] 2 +</PRE> + +<P>and get a Logo error message, you might feel that it's obvious +what you meant--and it would be, to another person--and so Logo should +have figured it out and done the right thing. But computers aren't as +smart as people, and so you can rely only on Logo's syntax rules, not on the +semantics of your program, to help Logo make sense of what you write. + +<P>To illustrate the difference between syntax and semantics, we'll start by +examining the following Logo instruction: + +<P><PRE>? <U>print word sum 2 4 "es</U> +6es +</PRE> + +<P>Here's its plumbing diagram: + +<P><CENTER><IMG SRC="sixes.gif" ALT="figure: sixes"></CENTER> + +<P>The connections in a plumbing diagram depend only on the numbers of inputs +and outputs for each procedure used. Logo "connects the plumbing" <EM> +before</EM> invoking any of the procedures named in the instruction. The +plumbing is connected regardless of whether the specified inputs actually +make sense to the procedures in question. For example, suppose we make a +slight change to the instruction given just now: + +<P><PRE>print sum word 2 4 "es +</PRE> + +<P>The only change is that <CODE>word</CODE> and <CODE>sum</CODE> have been +interchanged. Since these are both two-input operations, the shape of the +plumbing diagram is unchanged. + +<P><CENTER><IMG SRC="semantics.gif" ALT="figure: semantics"></CENTER> + +<P>The plumbing connections are syntactically fine, so Logo can work +out which expression provides the input to which procedure call. However, +when Logo gets around to invoking the procedure <CODE>sum</CODE> with inputs <CODE> +24</CODE> and <CODE>es</CODE>, an error message will result because the second input +isn't a number. This is a <EM>semantic</EM> error. + +<P>By contrast, the following instruction shows a <EM>syntactic</EM> error, in +which Logo is unable to figure out a plumbing diagram in which all the +pieces connect up. + +<P><PRE>print word sum 2 "es +</PRE> +<P><CENTER><IMG SRC="https://people.eecs.berkeley.edu/~bh/v1ch2/syntax.gif" ALT="figure: syntax"></CENTER> + +<P>The question mark in the diagram indicates a missing input. In +this example, the programmer intended the word <CODE>es</CODE> to be the second +input to <CODE>word</CODE>; from the programmer's point of view, it is a number, +the desired second input to <CODE>sum</CODE>, that's "really" missing. But Logo +doesn't know about the programmer's intentions, and Logo's plumber follows +uniform rules in deciding which input goes with which procedure call. + +<P>The rule is that Logo starts by looking for an input to <CODE>print</CODE>. The +first thing it finds is <CODE>word</CODE>, so the output from <CODE>word</CODE> is hooked +up to the input for <CODE>print</CODE>. Now Logo is looking for two inputs to <CODE> +word</CODE>. The next thing it finds is <CODE>sum</CODE>, so the output from <CODE>sum</CODE> +is hooked up to the first input for <CODE>word</CODE>. Now Logo is looking for two +inputs to <CODE>sum</CODE>, and the syntax rules say that Logo must find those two +inputs before it can continue with the still-pending task of finding a +second input for <CODE>word</CODE>. Logo's plumber isn't smart enough to say, +"Hey, here's a non-number as input to <CODE>sum</CODE>, and I happen to remember +that we still need another input for <CODE>word</CODE>, so that must be what the +programmer meant." + +<P>There are really only two kinds of plumbing errors. In the one shown here, +too few expressions are included in the instruction, so that the message +<CODE>not enough inputs</CODE> results. The other error is that too many +expressions appear inside the instruction. This may result in the message +<CODE>you don't say what to do with</CODE> something, or, if the extra expressions +are within parentheses, by <CODE>too much inside ()'s</CODE>. + +<P><H2>Parentheses and Plumbing Diagrams</H2> + +<P>Parentheses can be used in a Logo instruction for three reasons: for +readability, to show the precedence of infix operators, or to include a +nonstandard number of inputs for certain primitives. In all three cases, +the syntax rule is that everything inside the parentheses must form one +single complete expression. In plumbing diagram terms, this means that the +stuff inside the parentheses must correspond to a subdiagram with no inputs +and with exactly one output (unless an entire instruction is parenthesized, +in which case the diagram will have no outputs): + +<P><PRE>print (word "a "b "c) +</PRE> +<P><CENTER><IMG SRC="okparens.gif" ALT="figure: okparens"></CENTER> + +<P>The dotted rectangle indicates the subdiagram corresponding to the +expression inside the parentheses. That rectangle has no inputs; there are +three inputs <EM>within</EM> the rectangle, but in each case the source of +the input and the recipient of the input are both inside. There is no +recipient inside the rectangle that needs a source from outside. The +rectangle has one output; the entire expression within the rectangle +provides the input to <CODE>print</CODE>. + +<P>The mathematical function notation <EM>f</EM>(<EM>x</EM>) used in algebra often tempts +beginning Logo programmers to write the above example as + +<P><PRE>print word ("a "b "c) ; (wrong) +</PRE> + +<P>but by thinking about the plumbing diagram we can see that that +would not put one single expression inside the parentheses: + +<P><CENTER><IMG SRC="badparens.gif" ALT="figure: badparens"></CENTER> + +<P>The part of the instruction inside the parentheses is trying to provide +three outputs, not just one. This violates the rules. Also, since the word +<CODE>word</CODE> isn't inside the parentheses, that procedure follows its ordinary +rules and expects only two inputs. + +<P><H2>Nonsense Plumbing Diagrams</H2> + +<P>To emphasize the point that the plumbing diagram depends only on the number +of inputs expected by each procedure, and not on the purpose or meaning of +the procedure, we can draw plumbing diagrams for nonsense instructions using +unknown procedures. The rule of this game is that each procedure name +includes a number indicating how many inputs it accepts. For example, +<CODE>garply2</CODE> is a procedure that requires two inputs. If a procedure can +accept extra inputs when used with parentheses, we put an <CODE>x</CODE> after the +number; <CODE>baz3x</CODE> ordinarily takes three inputs, but can be given any +number of inputs by using parentheses around the subexpression that invokes +it. + +<P><PRE>john2 "paul george2 ringo0 "stu +</PRE> +<P><CENTER><IMG SRC="https://people.eecs.berkeley.edu/~bh/v1ch2/nonsense.gif" ALT="figure: nonsense"></CENTER> + +<P>We don't have to know what any of these procedures do. The only +information we need is that some words in the instruction are quoted, while +others are names of procedures that take a known number of inputs. This is +a syntactically correct instruction because each procedure has been given +exactly as many inputs as it requires. + +<P>»Try these: + +<P><PRE>baz3x 1 2 foo3x foo3x 4 5 6 (foo3x 7) 8 +baz3x 1 [2 foo3x foo3x 4 5 6 (foo3x 7)] 8 +if2 test3 [a b] [c d] [e f] [g h] +if2 try0 [foo3x 8 9] +</PRE> + +<P><A HREF="../v1-toc2.html">(back to Table of Contents)</A> +<P><A HREF="../v1ch1/v1ch1.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="../v1ch3/v1ch3.html"><STRONG>NEXT</STRONG></A> + +<P> +<ADDRESS> +<A HREF="../index.html">Brian Harvey</A>, +<CODE>bh@cs.berkeley.edu</CODE> +</ADDRESS> +</BODY> +</HTML> diff --git a/js/games/nluqo.github.io/~bh/v1ch2/semantics.gif b/js/games/nluqo.github.io/~bh/v1ch2/semantics.gif new file mode 100644 index 0000000..cdcce58 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/semantics.gif Binary files differdiff --git a/js/games/nluqo.github.io/~bh/v1ch2/sixes.gif b/js/games/nluqo.github.io/~bh/v1ch2/sixes.gif new file mode 100644 index 0000000..783435d --- /dev/null +++ b/js/games/nluqo.github.io/~bh/v1ch2/sixes.gif Binary files differ |
