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/part6.html | |
| parent | 5d012c6c011a9dedf7d0a098e456206244eb5a0f (diff) | |
| download | tour-562a9a52d599d9a05f871404050968a5fd282640.tar.gz | |
*
Diffstat (limited to 'js/games/nluqo.github.io/~bh/part6.html')
| -rw-r--r-- | js/games/nluqo.github.io/~bh/part6.html | 95 |
1 files changed, 95 insertions, 0 deletions
diff --git a/js/games/nluqo.github.io/~bh/part6.html b/js/games/nluqo.github.io/~bh/part6.html new file mode 100644 index 0000000..47b8702 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/part6.html @@ -0,0 +1,95 @@ +<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> |