<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>