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/ssch20/part6.html | |
parent | 5d012c6c011a9dedf7d0a098e456206244eb5a0f (diff) | |
download | tour-562a9a52d599d9a05f871404050968a5fd282640.tar.gz |
*
Diffstat (limited to 'js/games/nluqo.github.io/~bh/ssch20/part6.html')
-rw-r--r-- | js/games/nluqo.github.io/~bh/ssch20/part6.html | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/js/games/nluqo.github.io/~bh/ssch20/part6.html b/js/games/nluqo.github.io/~bh/ssch20/part6.html new file mode 100644 index 0000000..ac9eabe --- /dev/null +++ b/js/games/nluqo.github.io/~bh/ssch20/part6.html @@ -0,0 +1,111 @@ +<P> + +<P> +<HTML> +<HEAD> +<TITLE>Simply Scheme: Introducing Computer Science, Part 20: Sequential Programming</TITLE> +</HEAD> +<BODY> +<CITE>Simply Scheme:</CITE> +<CITE>Introducing Computer Science</CITE> 2/e Copyright (C) 1999 MIT +<H2>Part VI</H2> +<H1>Sequential Programming</H1> + +<TABLE width="100%"><TR><TD> +<IMG SRC="../simply.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"><CITE><A HREF="http://ccrma.stanford.edu/~matt">Matthew +Wright</A><BR>University of California, Santa Barbara</CITE> +<TR><TD align="right"><BR> +<TR><TD align="right"><A HREF="../pdf/ssch20.pdf">Download PDF version</A> +<TR><TD align="right"><A HREF="../ss-toc2.html">Back to Table of Contents</A> +<TR><TD align="right"><A HREF="../ssch19/implement-hof.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="io.html"><STRONG>NEXT</STRONG></A> +<TR><TD align="right"><A HREF="http://mitpress.mit.edu/0262082810">MIT +Press web page for <CITE>Simply Scheme</CITE></A> +</TABLE></TABLE> + +<HR><BIG> + +<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 + +<P><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: + +<P><P><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top">Interactive, question-and-answer programs that involve keyboard input +while the computation is in progress; +</TABLE><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top">Programs that must read and write long-term data file storage; +</TABLE><TABLE><TR><TH align="right" valign="top">•<TD> <TD valign="top">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. + +</TABLE><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> +</BIG> +<HR> +<P><A HREF="../ss-toc2.html">(back to Table of Contents)</A><P> +<A HREF="../ssch19/implement-hof.html"><STRONG>BACK</STRONG></A> +chapter thread <A HREF="io.html"><STRONG>NEXT</STRONG></A> + +<P> +<ADDRESS> +<A HREF="../index.html">Brian Harvey</A>, +<CODE>bh@cs.berkeley.edu</CODE> +</ADDRESS> +</BODY> +</HTML> |