about summary refs log blame commit diff stats
path: root/js/games/nluqo.github.io/~bh/part6.html
blob: 47b87021ad1bc4b9bd41f6132c361406700963dc (plain) (tree)






























































































                                                                                        
<HTML>
<HEAD>
<TITLE>Simply Scheme part VI introduction</TITLE>
</HEAD>
<BODY>
<CITE>Simply Scheme</CITE> 2/e Copyright (C) 1999 MIT
<H1>Sequential Programming</H1>

<TABLE><TR><TD>
<P><IMG SRC="simply.jpg" ALT="cover photo">
<TD valign="center">
<CITE><A HREF="http://www.cs.berkeley.edu/~bh/">Brian
Harvey</A><BR><A HREF="http://www.cnmat.berkeley.edu/~matt">Matthew
Wright</A><BR>University of California, Berkeley</CITE>
<BR><BR><A HREF="http://www-mitpress.mit.edu/book-home.tcl?isbn=0262082810">MIT
Press web page for Simply Scheme</A>
</TABLE>

<P><A HREF="simply-toc.html">(back to Table of Contents)</A>

<HR>

<P>The three big ideas in this part are <EM>effect, sequence,</EM> and <EM>state.</EM>

<P>Until now, we've been doing functional programming, where the focus is on
functions and their return values.  Invoking a function is like asking a
question: "What's two plus two?" In this part of the book we're going to
talk about giving commands to the computer as well as asking it questions.
That is, we'll invoke procedures that tell Scheme to <EM>do</EM> something,
such as <CODE>wash-the-dishes</CODE>.  (Unfortunately, the Scheme standard
leaves out this primitive.)  Instead of merely computing a value, such a
procedure has an <EM>effect,</EM> an action that changes something.

<P>Once we're thinking about actions, it's very natural to consider
a <EM>sequence</EM> of actions.  First cooking dinner, then eating, and then washing
the dishes is one sequence.  First eating, then washing the dishes, and then
cooking is a much less sensible sequence.

<P>Although these ideas of sequence and effect are coming near the end of our
book, they're the ideas with which almost every introduction to programming
begins. Most books compare a program to a recipe or a sequence of
instructions, along the lines of

<PRE>
to go-to-work
  get-dressed
  eat-breakfast
  catch-the-bus
</PRE>

<P>This sequential programming style is simple and natural, and it does
a good job of modeling computations in which the problem concerns
a sequence of events.  If you're writing an airline reservation system, a
sequential program with <CODE>reserve-seat</CODE> and <CODE>issue-ticket</CODE> commands
makes sense.  But if you want to know the acronym of a phrase, that's
not inherently sequential, and a question-asking approach is best.

<P>Some actions that Scheme can take affect the "outside" world, such as
printing something on the computer screen.  But Scheme can also carry out
internal actions, invisible outside the computer, but changing the
environment in which Scheme itself carries out computations.  Defining a new
variable with <CODE>define</CODE> is an example; before the definition, Scheme
wouldn't understand what that name means, but once the definition has been
made, the name can be used in evaluating later expressions.  Scheme's
knowledge about the leftover effects of past computations is called
its <EM>state.</EM> The third big idea in this part of the book is that we can write
programs that maintain state information and use it to determine their
results.

<P>Like sequence, the notion of state contradicts functional programming.
Earlier in the book, we emphasized that every time a function is invoked
with the same arguments, it must return the same value.  But a procedure
whose returned value depends on state--on the past history of the
computation--might return a different value on each invocation, even with
identical arguments.

<P>We'll explore several situations in which effects,
sequence, and state are useful:

<UL>
<LI>Interactive, question-and-answer programs that involve keyboard input
while the computation is in progress;
<LI>Programs that must read and write long-term data file storage;
<LI>Computations that <EM>model</EM> an actual sequence of events in time
and use the state of the program to model information about the state of
the simulated events.
</UL>

<P>After introducing Scheme's mechanisms for sequential programming, we'll use
those mechanisms to implement versions of two commonly used types of
business computer applications, a spreadsheet and a database program.

<P><A HREF="simply-toc.html">(back to Table of Contents)</A>
</BODY>
</HTML>