Commit | Line | Data |
---|---|---|
a0e07ba4 NJ |
1 | @page |
2 | @node Basic Ideas | |
3 | @chapter Basic Ideas in Scheme | |
4 | ||
5 | In this chapter, we introduce the basic concepts that underpin the | |
6 | elegance and power of the Scheme language. | |
7 | ||
8 | Readers who already possess a background knowledge of Scheme may happily | |
9 | skip this chapter. For the reader who is new to the language, however, | |
10 | the following discussions on data, procedures, expressions and closure | |
11 | are designed to provide a minimum level of Scheme understanding that is | |
12 | more or less assumed by the reference chapters that follow. | |
13 | ||
14 | The style of this introductory material aims about halfway between the | |
15 | terse precision of R5RS and the discursive randomness of a Scheme | |
16 | tutorial. | |
17 | ||
18 | @menu | |
19 | * About Data:: Latent typing, types, values and variables. | |
20 | * About Procedures:: The representation and use of procedures. | |
21 | * About Expressions:: All kinds of expressions and their meaning. | |
22 | * About Closure:: Closure, scoping and environments. | |
23 | @end menu | |
24 | ||
25 | ||
26 | @node About Data | |
27 | @section Data Types, Values and Variables | |
28 | ||
29 | This section discusses the representation of data types and values, what | |
30 | it means for Scheme to be a @dfn{latently typed} language, and the role | |
31 | of variables. We conclude by introducing the Scheme syntaxes for | |
32 | defining a new variable, and for changing the value of an existing | |
33 | variable. | |
34 | ||
35 | @menu | |
36 | * Latent Typing:: Scheme as a "latently typed" language. | |
37 | * Values and Variables:: About data types, values and variables. | |
38 | * Definition:: Defining variables and setting their values. | |
39 | @end menu | |
40 | ||
41 | ||
42 | @node Latent Typing | |
43 | @subsection Latent Typing | |
44 | ||
45 | The term @dfn{latent typing} is used to descibe a computer language, | |
46 | such as Scheme, for which you cannot, @emph{in general}, simply look at | |
47 | a program's source code and determine what type of data will be | |
48 | associated with a particular variable, or with the result of a | |
49 | particular expression. | |
50 | ||
51 | Sometimes, of course, you @emph{can} tell from the code what the type of | |
52 | an expression will be. If you have a line in your program that sets the | |
53 | variable @code{x} to the numeric value 1, you can be certain that, | |
54 | immediately after that line has executed (and in the absence of multiple | |
55 | threads), @code{x} has the numeric value 1. Or if you write a procedure | |
56 | that is designed to concatenate two strings, it is likely that the rest | |
57 | of your application will always invoke this procedure with two string | |
58 | parameters, and quite probable that the procedure would go wrong in some | |
59 | way if it was ever invoked with parameters that were not both strings. | |
60 | ||
61 | Nevertheless, the point is that there is nothing in Scheme which | |
62 | requires the procedure parameters always to be strings, or @code{x} | |
63 | always to hold a numeric value, and there is no way of declaring in your | |
64 | program that such constraints should always be obeyed. In the same | |
65 | vein, there is no way to declare the expected type of a procedure's | |
66 | return value. | |
67 | ||
68 | Instead, the types of variables and expressions are only known -- in | |
69 | general -- at run time. If you @emph{need} to check at some point that | |
70 | a value has the expected type, Scheme provides run time procedures that | |
71 | you can invoke to do so. But equally, it can be perfectly valid for two | |
72 | separate invocations of the same procedure to specify arguments with | |
73 | different types, and to return values with different types. | |
74 | ||
75 | The next subsection explains what this means in practice, for the ways | |
76 | that Scheme programs use data types, values and variables. | |
77 | ||
78 | ||
79 | @node Values and Variables | |
80 | @subsection Values and Variables | |
81 | ||
82 | Scheme provides many data types that you can use to represent your data. | |
83 | Primitive types include characters, strings, numbers and procedures. | |
84 | Compound types, which allow a group of primitive and compound values to | |
85 | be stored together, include lists, pairs, vectors and multi-dimensional | |
86 | arrays. In addition, Guile allows applications to define their own data | |
87 | types, with the same status as the built-in standard Scheme types. | |
88 | ||
89 | As a Scheme program runs, values of all types pop in and out of | |
90 | existence. Sometimes values are stored in variables, but more commonly | |
91 | they pass seamlessly from being the result of one computation to being | |
92 | one of the parameters for the next. | |
93 | ||
94 | Consider an example. A string value is created because the interpreter | |
95 | reads in a literal string from your program's source code. Then a | |
96 | numeric value is created as the result of calculating the length of the | |
97 | string. A second numeric value is created by doubling the calculated | |
98 | length. Finally the program creates a list with two elements -- the | |
99 | doubled length and the original string itself -- and stores this list in | |
100 | a program variable. | |
101 | ||
102 | All of the values involved here -- in fact, all values in Scheme -- | |
103 | carry their type with them. In other words, every value ``knows,'' at | |
104 | runtime, what kind of value it is. A number, a string, a list, | |
105 | whatever. | |
106 | ||
107 | A variable, on the other hand, has no fixed type. A variable -- | |
108 | @code{x}, say -- is simply the name of a location -- a box -- in which | |
109 | you can store any kind of Scheme value. So the same variable in a | |
110 | program may hold a number at one moment, a list of procedures the next, | |
111 | and later a pair of strings. The ``type'' of a variable -- insofar as | |
112 | the idea is meaningful at all -- is simply the type of whatever value | |
113 | the variable happens to be storing at a particular moment. | |
114 | ||
115 | ||
116 | @node Definition | |
117 | @subsection Defining and Setting Variables | |
118 | ||
119 | To define a new variable, you use Scheme's @code{define} syntax like | |
120 | this: | |
121 | ||
122 | @lisp | |
123 | (define @var{variable-name} @var{value}) | |
124 | @end lisp | |
125 | ||
126 | This makes a new variable called @var{variable-name} and stores | |
127 | @var{value} in it as the variable's initial value. For example: | |
128 | ||
129 | @lisp | |
130 | ;; Make a variable `x' with initial numeric value 1. | |
131 | (define x 1) | |
132 | ||
133 | ;; Make a variable `organization' with an initial string value. | |
134 | (define organization "Free Software Foundation") | |
135 | @end lisp | |
136 | ||
137 | (In Scheme, a semicolon marks the beginning of a comment that continues | |
138 | until the end of the line. So the lines beginning @code{;;} are | |
139 | comments.) | |
140 | ||
141 | Changing the value of an already existing variable is very similar, | |
142 | except that @code{define} is replaced by the Scheme syntax @code{set!}, | |
143 | like this: | |
144 | ||
145 | @lisp | |
146 | (set! @var{variable-name} @var{new-value}) | |
147 | @end lisp | |
148 | ||
149 | Remember that variables do not have fixed types, so @var{new-value} may | |
150 | have a completely different type from whatever was previously stored in | |
151 | the location named by @var{variable-name}. Both of the following | |
152 | examples are therefore correct. | |
153 | ||
154 | @lisp | |
155 | ;; Change the value of `x' to 5. | |
156 | (set! x 5) | |
157 | ||
158 | ;; Change the value of `organization' to the FSF's street number. | |
159 | (set! organization 545) | |
160 | @end lisp | |
161 | ||
162 | In these examples, @var{value} and @var{new-value} are literal numeric | |
163 | or string values. In general, however, @var{value} and @var{new-value} | |
164 | can be any Scheme expression. Even though we have not yet covered the | |
165 | forms that Scheme expressions can take (@pxref{About Expressions}), you | |
166 | can probably guess what the following @code{set!} example does@dots{} | |
167 | ||
168 | @lisp | |
169 | (set! x (+ x 1)) | |
170 | @end lisp | |
171 | ||
172 | (Note: this is not a complete description of @code{define} and | |
173 | @code{set!}, because we need to introduce some other aspects of Scheme | |
174 | before the missing pieces can be filled in. If, however, you are | |
175 | already familiar with the structure of Scheme, you may like to read | |
176 | about those missing pieces immediately by jumping ahead to the following | |
177 | references. | |
178 | ||
179 | @itemize @bullet | |
180 | @item | |
181 | @xref{Internal Definitions}, to read about using @code{define} other | |
182 | than at top level in a Scheme program, including a discussion of when it | |
183 | works to use @code{define} rather than @code{set!} to change the value | |
184 | of an existing variable. | |
185 | ||
186 | @item | |
187 | @ref{Lambda Alternatives}, to read about an alternative form of the | |
188 | @code{define} syntax that can be used when defining new procedures. | |
189 | ||
190 | @item | |
191 | REFFIXME, to read about an alternative form of the @code{set!} syntax | |
192 | that helps with changing a single value in the depths of a compound data | |
193 | structure.) | |
194 | @end itemize | |
195 | ||
196 | ||
197 | @node About Procedures | |
198 | @section The Representation and Use of Procedures | |
199 | ||
200 | This section introduces the basics of using and creating Scheme | |
201 | procedures. It discusses the representation of procedures as just | |
202 | another kind of Scheme value, and shows how procedure invocation | |
203 | expressions are constructed. We then explain how @code{lambda} is used | |
204 | to create new procedures, and conclude by presenting the various | |
205 | shorthand forms of @code{define} that can be used instead of writing an | |
206 | explicit @code{lambda} expression. | |
207 | ||
208 | @menu | |
209 | * Procedures as Values:: Procedures are values like everything else. | |
210 | * Simple Invocation:: How to write a simple procedure invocation. | |
211 | * Creating a Procedure:: How to create your own procedures. | |
212 | * Lambda Alternatives:: Other ways of writing procedure definitions. | |
213 | @end menu | |
214 | ||
215 | ||
216 | @node Procedures as Values | |
217 | @subsection Procedures as Values | |
218 | ||
219 | One of the great simplifications of Scheme is that a procedure is just | |
220 | another type of value, and that procedure values can be passed around | |
221 | and stored in variables in exactly the same way as, for example, strings | |
222 | and lists. When we talk about a built-in standard Scheme procedure such | |
223 | as @code{open-input-file}, what we actually mean is that there is a | |
224 | pre-defined top level variable called @code{open-input-file}, whose | |
225 | value is a procedure that implements what R5RS says that | |
226 | @code{open-input-file} should do. | |
227 | ||
228 | Note that this is quite different from many dialects of Lisp --- | |
229 | including Emacs Lisp --- in which a program can use the same name with | |
230 | two quite separate meanings: one meaning identifies a Lisp function, | |
231 | while the other meaning identifies a Lisp variable, whose value need | |
232 | have nothing to do with the function that is associated with the first | |
233 | meaning. In these dialects, functions and variables are said to live in | |
234 | different @dfn{namespaces}. | |
235 | ||
236 | In Scheme, on the other hand, all names belong to a single unified | |
237 | namespace, and the variables that these names identify can hold any kind | |
238 | of Scheme value, including procedure values. | |
239 | ||
240 | One consequence of the ``procedures as values'' idea is that, if you | |
241 | don't happen to like the standard name for a Scheme procedure, you can | |
242 | change it. | |
243 | ||
244 | For example, @code{call-with-current-continuation} is a very important | |
245 | standard Scheme procedure, but it also has a very long name! So, many | |
246 | programmers use the following definition to assign the same procedure | |
247 | value to the more convenient name @code{call/cc}. | |
248 | ||
249 | @lisp | |
250 | (define call/cc call-with-current-continuation) | |
251 | @end lisp | |
252 | ||
253 | Let's understand exactly how this works. The definition creates a new | |
254 | variable @code{call/cc}, and then sets its value to the value of the | |
255 | variable @code{call-with-current-continuation}; the latter value is a | |
256 | procedure that implements the behaviour that R5RS specifies under the | |
257 | name ``call-with-current-continuation''. So @code{call/cc} ends up | |
258 | holding this value as well. | |
259 | ||
260 | Now that @code{call/cc} holds the required procedure value, you could | |
261 | choose to use @code{call-with-current-continuation} for a completely | |
262 | different purpose, or just change its value so that you will get an | |
263 | error if you accidentally use @code{call-with-current-continuation} as a | |
264 | procedure in your program rather than @code{call/cc}. For example: | |
265 | ||
266 | @lisp | |
267 | (set! call-with-current-continuation "Not a procedure any more!") | |
268 | @end lisp | |
269 | ||
270 | Or you could just leave @code{call-with-current-continuation} as it was. | |
271 | It's perfectly fine for more than one variable to hold the same | |
272 | procedure value. | |
273 | ||
274 | ||
275 | @node Simple Invocation | |
276 | @subsection Simple Procedure Invocation | |
277 | ||
278 | A procedure invocation in Scheme is written like this: | |
279 | ||
280 | @lisp | |
281 | (@var{procedure} [@var{arg1} [@var{arg2} @dots{}]]) | |
282 | @end lisp | |
283 | ||
284 | In this expression, @var{procedure} can be any Scheme expression whose | |
285 | value is a procedure. Most commonly, however, @var{procedure} is simply | |
286 | the name of a variable whose value is a procedure. | |
287 | ||
288 | For example, @code{string-append} is a standard Scheme procedure whose | |
289 | behaviour is to concatenate together all the arguments, which are | |
290 | expected to be strings, that it is given. So the expression | |
291 | ||
292 | @lisp | |
293 | (string-append "/home" "/" "andrew") | |
294 | @end lisp | |
295 | ||
296 | @noindent | |
297 | is a procedure invocation whose result is the string value | |
298 | @code{"/home/andrew"}. | |
299 | ||
300 | Similarly, @code{string-length} is a standard Scheme procedure that | |
301 | returns the length of a single string argument, so | |
302 | ||
303 | @lisp | |
304 | (string-length "abc") | |
305 | @end lisp | |
306 | ||
307 | @noindent | |
308 | is a procedure invocation whose result is the numeric value 3. | |
309 | ||
310 | Each of the parameters in a procedure invocation can itself be any | |
311 | Scheme expression. Since a procedure invocation is itself a type of | |
312 | expression, we can put these two examples together to get | |
313 | ||
314 | @lisp | |
315 | (string-length (string-append "/home" "/" "andrew")) | |
316 | @end lisp | |
317 | ||
318 | @noindent | |
319 | --- a procedure invocation whose result is the numeric value 12. | |
320 | ||
321 | (You may be wondering what happens if the two examples are combined the | |
322 | other way round. If we do this, we can make a procedure invocation | |
323 | expression that is @emph{syntactically} correct: | |
324 | ||
325 | @lisp | |
326 | (string-append "/home" (string-length "abc")) | |
327 | @end lisp | |
328 | ||
329 | @noindent | |
330 | but when this expression is executed, it will cause an error, because | |
331 | the result of @code{(string-length "abc")} is a numeric value, and | |
332 | @code{string-append} is not designed to accept a numeric value as one of | |
333 | its arguments.) | |
334 | ||
335 | ||
336 | @node Creating a Procedure | |
337 | @subsection Creating and Using a New Procedure | |
338 | ||
339 | Scheme has lots of standard procedures, and Guile provides all of these | |
340 | via predefined top level variables. All of these standard procedures | |
341 | are documented in the later chapters of this reference manual. | |
342 | ||
343 | Before very long, though, you will want to create new procedures that | |
344 | encapsulate aspects of your own applications' functionality. To do | |
345 | this, you can use the famous @code{lambda} syntax. | |
346 | ||
347 | For example, the value of the following Scheme expression | |
348 | ||
349 | @lisp | |
350 | (lambda (name address) @var{expression} @dots{}) | |
351 | @end lisp | |
352 | ||
353 | @noindent | |
354 | is a newly created procedure that takes two arguments: | |
355 | @code{name} and @code{address}. The behaviour of the | |
356 | new procedure is determined by the sequence of @var{expression}s in the | |
357 | @dfn{body} of the procedure definition. (Typically, these | |
358 | @var{expression}s would use the arguments in some way, or else there | |
359 | wouldn't be any point in giving them to the procedure.) When invoked, | |
360 | the new procedure returns a value that is the value of the last | |
361 | @var{expression} in the procedure body. | |
362 | ||
363 | To make things more concrete, let's suppose that the two arguments are | |
364 | both strings, and that the purpose of this procedure is to form a | |
365 | combined string that includes these arguments. Then the full lambda | |
366 | expression might look like this: | |
367 | ||
368 | @lisp | |
369 | (lambda (name address) | |
370 | (string-append "Name=" name ":Address=" address)) | |
371 | @end lisp | |
372 | ||
373 | We noted in the previous subsection that the @var{procedure} part of a | |
374 | procedure invocation expression can be any Scheme expression whose value | |
375 | is a procedure. But that's exactly what a lambda expression is! So we | |
376 | can use a lambda expression directly in a procedure invocation, like | |
377 | this: | |
378 | ||
379 | @lisp | |
380 | ((lambda (name address) | |
381 | (string-append "Name=" name ":Address=" address)) | |
382 | "FSF" | |
383 | "Cambridge") | |
384 | @end lisp | |
385 | ||
386 | @noindent | |
387 | This is a valid procedure invocation expression, whose result is the | |
388 | string @code{"Name=FSF:Address=Cambridge"}. | |
389 | ||
390 | It it more common, though, to store the procedure value in a variable --- | |
391 | ||
392 | @lisp | |
393 | (define make-combined-string | |
394 | (lambda (name address) | |
395 | (string-append "Name=" name ":Address=" address))) | |
396 | @end lisp | |
397 | ||
398 | @noindent | |
399 | --- and then to use the variable name in the procedure invocation: | |
400 | ||
401 | @lisp | |
402 | (make-combined-string "FSF" "Cambridge") | |
403 | @end lisp | |
404 | ||
405 | @noindent | |
406 | Which has exactly the same result. | |
407 | ||
408 | It's important to note that procedures created using @code{lambda} have | |
409 | exactly the same status as the standard built in Scheme procedures, and | |
410 | can be invoked, passed around, and stored in variables in exactly the | |
411 | same ways. | |
412 | ||
413 | ||
414 | @node Lambda Alternatives | |
415 | @subsection Lambda Alternatives | |
416 | ||
417 | Since it is so common in Scheme programs to want to create a procedure | |
418 | and then store it in a variable, there is an alternative form of the | |
419 | @code{define} syntax that allows you to do just that. | |
420 | ||
421 | A @code{define} expression of the form | |
422 | ||
423 | @lisp | |
424 | (define (@var{name} [@var{arg1} [@var{arg2} @dots{}]]) | |
425 | @var{expression} @dots{}) | |
426 | @end lisp | |
427 | ||
428 | @noindent | |
429 | is exactly equivalent to the longer form | |
430 | ||
431 | @lisp | |
432 | (define @var{name} | |
433 | (lambda ([@var{arg1} [@var{arg2} @dots{}]]) | |
434 | @var{expression} @dots{})) | |
435 | @end lisp | |
436 | ||
437 | So, for example, the definition of @code{make-combined-string} in the | |
438 | previous subsection could equally be written: | |
439 | ||
440 | @lisp | |
441 | (define (make-combined-string name address) | |
442 | (string-append "Name=" name ":Address=" address)) | |
443 | @end lisp | |
444 | ||
445 | This kind of procedure definition creates a procedure that requires | |
446 | exactly the expected number of arguments. There are two further forms | |
447 | of the @code{lambda} expression, which create a procedure that can | |
448 | accept a variable number of arguments: | |
449 | ||
450 | @lisp | |
451 | (lambda (@var{arg1} @dots{} . @var{args}) @var{expression} @dots{}) | |
452 | ||
453 | (lambda @var{args} @var{expression} @dots{}) | |
454 | @end lisp | |
455 | ||
456 | @noindent | |
457 | The corresponding forms of the alternative @code{define} syntax are: | |
458 | ||
459 | @lisp | |
460 | (define (@var{name} @var{arg1} @dots{} . @var{args}) @var{expression} @dots{}) | |
461 | ||
462 | (define (@var{name} . @var{args}) @var{expression} @dots{}) | |
463 | @end lisp | |
464 | ||
465 | @noindent | |
466 | For details on how these forms work, see @xref{Lambda}. | |
467 | ||
468 | (It could be argued that the alternative @code{define} forms are rather | |
469 | confusing, especially for newcomers to the Scheme language, as they hide | |
470 | both the role of @code{lambda} and the fact that procedures are values | |
471 | that are stored in variables in the some way as any other kind of value. | |
472 | On the other hand, they are very convenient, and they are also a good | |
473 | example of another of Scheme's powerful features: the ability to specify | |
474 | arbitrary syntactic transformations at run time, which can be applied to | |
475 | subsequently read input.) | |
476 | ||
477 | ||
478 | @node About Expressions | |
479 | @section Expressions and Evaluation | |
480 | ||
481 | So far, we have met expressions that @emph{do} things, such as the | |
482 | @code{define} expressions that create and initialize new variables, and | |
483 | we have also talked about expressions that have @emph{values}, for | |
484 | example the value of the procedure invocation expression: | |
485 | ||
486 | @lisp | |
487 | (string-append "/home" "/" "andrew") | |
488 | @end lisp | |
489 | ||
490 | @noindent | |
491 | but we haven't yet been precise about what causes an expression like | |
492 | this procedure invocation to be reduced to its ``value'', or how the | |
493 | processing of such expressions relates to the execution of a Scheme | |
494 | program as a whole. | |
495 | ||
496 | This section clarifies what we mean by an expression's value, by | |
497 | introducing the idea of @dfn{evaluation}. It discusses the side effects | |
498 | that evaluation can have, explains how each of the various types of | |
499 | Scheme expression is evaluated, and describes the behaviour and use of | |
500 | the Guile REPL as a mechanism for exploring evaluation. The section | |
501 | concludes with a very brief summary of Scheme's common syntactic | |
502 | expressions. | |
503 | ||
504 | @menu | |
505 | * Evaluating:: How a Scheme program is executed. | |
506 | * The REPL:: Interacting with the Guile interpreter. | |
507 | * Syntax Summary:: Common syntactic expressions -- in brief. | |
508 | @end menu | |
509 | ||
510 | ||
511 | @node Evaluating | |
512 | @subsection Evaluating Expressions and Executing Programs | |
513 | ||
514 | In Scheme, the process of executing an expression is known as | |
515 | @dfn{evaluation}. Evaluation has two kinds of result: | |
516 | ||
517 | @itemize @bullet | |
518 | @item | |
519 | the @dfn{value} of the evaluated expression | |
520 | ||
521 | @item | |
522 | the @dfn{side effects} of the evaluation, which consist of any effects of | |
523 | evaluating the expression that are not represented by the value. | |
524 | @end itemize | |
525 | ||
526 | Of the expressions that we have met so far, @code{define} and | |
527 | @code{set!} expressions have side effects --- the creation or | |
528 | modification of a variable --- but no value; @code{lambda} expressions | |
529 | have values --- the newly constructed procedures --- but no side | |
530 | effects; and procedure invocation expressions, in general, have either | |
531 | values, or side effects, or both. | |
532 | ||
533 | It is tempting to try to define more intuitively what we mean by | |
534 | ``value'' and ``side effects'', and what the difference between them is. | |
535 | In general, though, this is extremely difficult. It is also | |
536 | unnecessary; instead, we can quite happily define the behaviour of a | |
537 | Scheme program by specifying how Scheme executes a program as a whole, | |
538 | and then by describing the value and side effects of evaluation for each | |
539 | type of expression individually. | |
540 | ||
541 | @noindent | |
542 | So, some@footnote{These definitions are approximate. For the whole and | |
543 | detailed truth, see @xref{Formal syntax and semantics,R5RS | |
544 | syntax,,r5rs}.} definitions@dots{} | |
545 | ||
546 | @itemize @bullet | |
547 | ||
548 | @item | |
549 | A Scheme program consists of a sequence of expressions. | |
550 | ||
551 | @item | |
552 | A Scheme interpreter executes the program by evaluating these | |
553 | expressions in order, one by one. | |
554 | ||
555 | @item | |
556 | An expression can be | |
557 | ||
558 | @itemize @bullet | |
559 | @item | |
560 | a piece of literal data, such as a number @code{2.3} or a string | |
561 | @code{"Hello world!"} | |
562 | @item | |
563 | a variable name | |
564 | @item | |
565 | a procedure invocation expression | |
566 | @item | |
567 | one of Scheme's special syntactic expressions. | |
568 | @end itemize | |
569 | @end itemize | |
570 | ||
571 | @noindent | |
572 | The following subsections describe how each of these types of expression | |
573 | is evaluated. | |
574 | ||
575 | @menu | |
576 | * Eval Literal:: Evaluating literal data. | |
577 | * Eval Variable:: Evaluating variable references. | |
578 | * Eval Procedure:: Evaluating procedure invocation expressions. | |
579 | * Eval Special:: Evaluating special syntactic expressions. | |
580 | @end menu | |
581 | ||
582 | @node Eval Literal | |
583 | @subsubsection Evaluating Literal Data | |
584 | ||
585 | When a literal data expression is evaluated, the value of the expression | |
586 | is simply the value that the expression describes. The evaluation of a | |
587 | literal data expression has no side effects. | |
588 | ||
589 | @noindent | |
590 | So, for example, | |
591 | ||
592 | @itemize @bullet | |
593 | @item | |
594 | the value of the expression @code{"abc"} is the string value | |
595 | @code{"abc"} | |
596 | ||
597 | @item | |
598 | the value of the expression @code{3+4i} is the complex number 3 + 4i | |
599 | ||
600 | @item | |
601 | the value of the expression @code{#(1 2 3)} is a three-element vector | |
602 | containing the numeric values 1, 2 and 3. | |
603 | @end itemize | |
604 | ||
605 | For any data type which can be expressed literally like this, the syntax | |
606 | of the literal data expression for that data type --- in other words, | |
607 | what you need to write in your code to indicate a literal value of that | |
608 | type --- is known as the data type's @dfn{read syntax}. This manual | |
609 | specifies the read syntax for each such data type in the section that | |
610 | describes that data type. | |
611 | ||
612 | Some data types do not have a read syntax. Procedures, for example, | |
613 | cannot be expressed as literal data; they must be created using a | |
614 | @code{lambda} expression (@pxref{Creating a Procedure}) or implicitly | |
615 | using the shorthand form of @code{define} (@pxref{Lambda Alternatives}). | |
616 | ||
617 | ||
618 | @node Eval Variable | |
619 | @subsubsection Evaluating a Variable Reference | |
620 | ||
621 | When an expression that consists simply of a variable name is evaluated, | |
622 | the value of the expression is the value of the named variable. The | |
623 | evaluation of a variable reference expression has no side effects. | |
624 | ||
625 | So, after | |
626 | ||
627 | @lisp | |
628 | (define key "Paul Evans") | |
629 | @end lisp | |
630 | ||
631 | @noindent | |
632 | the value of the expression @code{key} is the string value @code{"Paul | |
633 | Evans"}. If @var{key} is then modified by | |
634 | ||
635 | @lisp | |
636 | (set! key 3.74) | |
637 | @end lisp | |
638 | ||
639 | @noindent | |
640 | the value of the expression @code{key} is the numeric value 3.74. | |
641 | ||
642 | If there is no variable with the specified name, evaluation of the | |
643 | variable reference expression signals an error. | |
644 | ||
645 | ||
646 | @node Eval Procedure | |
647 | @subsubsection Evaluating a Procedure Invocation Expression | |
648 | ||
649 | This is where evaluation starts getting interesting! As already noted, | |
650 | a procedure invocation expression has the form | |
651 | ||
652 | @lisp | |
653 | (@var{procedure} [@var{arg1} [@var{arg2} @dots{}]]) | |
654 | @end lisp | |
655 | ||
656 | @noindent | |
657 | where @var{procedure} must be an expression whose value, when evaluated, | |
658 | is a procedure. | |
659 | ||
660 | The evaluation of a procedure invocation expression like this proceeds | |
661 | by | |
662 | ||
663 | @itemize @bullet | |
664 | @item | |
665 | evaluating individually the expressions @var{procedure}, @var{arg1}, | |
666 | @var{arg2}, and so on | |
667 | ||
668 | @item | |
669 | calling the procedure that is the value of the @var{procedure} | |
670 | expression with the list of values obtained from the evaluations of | |
671 | @var{arg1}, @var{arg2} etc. as its parameters. | |
672 | @end itemize | |
673 | ||
674 | For a procedure defined in Scheme, ``calling the procedure with the list | |
675 | of values as its parameters'' means binding the values to the | |
676 | procedure's formal parameters and then evaluating the sequence of | |
677 | expressions that make up the body of the procedure definition. The | |
678 | value of the procedure invocation expression is the value of the last | |
679 | evaluated expression in the procedure body. The side effects of calling | |
680 | the procedure are the combination of the side effects of the sequence of | |
681 | evaluations of expressions in the procedure body. | |
682 | ||
683 | For a built-in procedure, the value and side-effects of calling the | |
684 | procedure are best described by that procedure's documentation. | |
685 | ||
686 | Note that the complete side effects of evaluating a procedure invocation | |
687 | expression consist not only of the side effects of the procedure call, | |
688 | but also of any side effects of the preceding evaluation of the | |
689 | expressions @var{procedure}, @var{arg1}, @var{arg2}, and so on. | |
690 | ||
691 | To illustrate this, let's look again at the procedure invocation | |
692 | expression: | |
693 | ||
694 | @lisp | |
695 | (string-length (string-append "/home" "/" "andrew")) | |
696 | @end lisp | |
697 | ||
698 | In the outermost expression, @var{procedure} is @code{string-length} and | |
699 | @var{arg1} is @code{(string-append "/home" "/" "andrew")}. | |
700 | ||
701 | @itemize @bullet | |
702 | @item | |
703 | Evaluation of @code{string-length}, which is a variable, gives a | |
704 | procedure value that implements the expected behaviour for | |
705 | ``string-length''. | |
706 | ||
707 | @item | |
708 | Evaluation of @code{(string-append "/home" "/" "andrew")}, which is | |
709 | another procedure invocation expression, means evaluating each of | |
710 | ||
711 | @itemize @bullet | |
712 | @item | |
713 | @code{string-append}, which gives a procedure value that implements the | |
714 | expected behaviour for ``string-append'' | |
715 | ||
716 | @item | |
717 | @code{"/home"}, which gives the string value @code{"/home"} | |
718 | ||
719 | @item | |
720 | @code{"/"}, which gives the string value @code{"/"} | |
721 | ||
722 | @item | |
723 | @code{"andrew"}, which gives the string value @code{"andrew"} | |
724 | @end itemize | |
725 | ||
726 | and then invoking the procedure value with this list of string values as | |
727 | its arguments. The resulting value is a single string value that is the | |
728 | concatenation of all the arguments, namely @code{"/home/andrew"}. | |
729 | @end itemize | |
730 | ||
731 | In the evaluation of the outermost expression, the interpreter can now | |
732 | invoke the procedure value obtained from @var{procedure} with the value | |
733 | obtained from @var{arg1} as its arguments. The resulting value is a | |
734 | numeric value that is the length of the argument string, which is 12. | |
735 | ||
736 | ||
737 | @node Eval Special | |
738 | @subsubsection Evaluating Special Syntactic Expressions | |
739 | ||
740 | When a procedure invocation expression is evaluated, the procedure and | |
741 | @emph{all} the argument expressions must be evaluated before the | |
742 | procedure can be invoked. Special syntactic expressions are special | |
743 | because they are able to manipulate their arguments in an unevaluated | |
744 | form, and can choose whether to evaluate any or all of the argument | |
745 | expressions. | |
746 | ||
747 | Why is this needed? Consider a program fragment that asks the user | |
748 | whether or not to delete a file, and then deletes the file if the user | |
749 | answers yes. | |
750 | ||
751 | @lisp | |
752 | (if (string=? (read-answer "Should I delete this file?") | |
753 | "yes") | |
754 | (delete-file file)) | |
755 | @end lisp | |
756 | ||
757 | If the outermost @code{(if @dots{})} expression here was a procedure | |
758 | invocation expression, the expression @code{(delete-file file)}, whose | |
759 | effect is to actually delete a file, would already have been executed | |
760 | before the @code{if} procedure even got invoked! Clearly this is no use | |
761 | --- the whole point of an @code{if} expression is that the | |
762 | @dfn{consequent} expression is only evaluated if the condition of the | |
763 | @code{if} expression is ``true''. | |
764 | ||
765 | Therefore @code{if} must be special syntax, not a procedure. Other | |
766 | special syntaxes that we have already met are @code{define}, @code{set!} | |
767 | and @code{lambda}. @code{define} and @code{set!} are syntax because | |
768 | they need to know the variable @emph{name} that is given as the first | |
769 | argument in a @code{define} or @code{set!} expression, not that | |
770 | variable's value. @code{lambda} is syntax because it does not | |
771 | immediately evaluate the expressions that define the procedure body; | |
772 | instead it creates a procedure object that incorporates these | |
773 | expressions so that they can be evaluated in the future, when that | |
774 | procedure is invoked. | |
775 | ||
776 | The rules for evaluating each special syntactic expression are specified | |
777 | individually for each special syntax. For a summary of standard special | |
778 | syntax, see @xref{Syntax Summary}. | |
779 | ||
780 | ||
781 | @node The REPL | |
782 | @subsection Using the Guile REPL | |
783 | ||
784 | If you start Guile without specifying a particular program for it to | |
785 | execute, Guile enters its standard Read Evaluate Print Loop --- or | |
786 | @dfn{REPL} for short. In this mode, Guile repeatedly reads in the next | |
787 | Scheme expression that the user types, evaluates it, and prints the | |
788 | resulting value. | |
789 | ||
790 | The REPL is a useful mechanism for exploring the evaluation behaviour | |
791 | described in the previous subsection. If you type @code{string-append}, | |
792 | for example, the REPL replies @code{#<primitive-procedure | |
793 | string-append>}, illustrating the relationship between the variable | |
794 | @code{string-append} and the procedure value stored in that variable. | |
795 | ||
796 | In this manual, the notation @result{} is used to mean ``evaluates | |
797 | to''. Wherever you see an example of the form | |
798 | ||
799 | @lisp | |
800 | @var{expression} | |
801 | @result{} | |
802 | @var{result} | |
803 | @end lisp | |
804 | ||
805 | @noindent | |
806 | feel free to try it out yourself by typing @var{expression} into the | |
807 | REPL and checking that it gives the expected @var{result}. | |
808 | ||
809 | ||
810 | @node Syntax Summary | |
811 | @subsection Summary of Common Syntax | |
812 | ||
813 | This subsection lists the most commonly used Scheme syntactic | |
814 | expressions, simply so that you will recognize common special syntax | |
815 | when you see it. For a full description of each of these syntaxes, | |
816 | follow the appropriate reference. | |
817 | ||
818 | @code{if} and @code{cond} (@pxref{if cond case}) provide conditional | |
819 | evaluation of argument expressions depending on whether one or more | |
820 | conditions evaluate to ``true'' or ``false''. | |
821 | ||
822 | @code{case} (@pxref{if cond case}) provides conditional evaluation of | |
823 | argument expressions depending on whether a variable has one of a | |
824 | specified group of values. | |
825 | ||
826 | @code{define} (REFFIXME) is used to create a new variable and set its | |
827 | initial value. | |
828 | ||
829 | @code{set!} (REFFIXME) is used to modify an existing variable's value. | |
830 | ||
831 | @code{lambda} (@pxref{Lambda}) is used to construct procedure objects. | |
832 | ||
833 | @code{let}, @code{let*} and @code{letrec} (@pxref{Local Bindings}) | |
834 | create an inner lexical environment for the evaluation of a sequence of | |
835 | expressions, in which a specified set of local variables is bound to the | |
836 | values of a corresponding set of expressions. For an introduction to | |
837 | environments, see @xref{About Closure}. | |
838 | ||
839 | @code{begin} (@pxref{begin}) executes a sequence of expressions in order | |
840 | and returns the value of the last expression. Note that this is not the | |
841 | same as a procedure which returns its last argument, because the | |
842 | evaluation of a procedure invocation expression does not guarantee to | |
843 | evaluate the arguments in order. | |
844 | ||
845 | @code{and} (@pxref{and or}) executes a sequence of expressions in order | |
846 | until either there are no expressions left, or one of them evaluates to | |
847 | ``false''. | |
848 | ||
849 | @code{or} (@pxref{and or}) executes a sequence of expressions in order | |
850 | until either there are no expressions left, or one of them evaluates to | |
851 | ``true''. | |
852 | ||
853 | ||
854 | @node About Closure | |
855 | @section The Concept of Closure | |
856 | ||
857 | @cindex closure | |
858 | ||
859 | The concept of @dfn{closure} is the idea that a lambda expression | |
860 | ``captures'' the variable bindings that are in lexical scope at the | |
861 | point where the lambda expression occurs. The procedure created by the | |
862 | lambda expression can refer to and mutate the captured bindings, and the | |
863 | values of those bindings persist between procedure calls. | |
864 | ||
865 | This section explains and explores the various parts of this idea in | |
866 | more detail. | |
867 | ||
868 | @menu | |
869 | * About Environments:: Names, locations, values and environments. | |
870 | * Local Variables:: Local variables and local environments. | |
871 | * Chaining:: Environment chaining. | |
872 | * Lexical Scope:: The meaning of lexical scoping. | |
873 | * Closure:: Explaining the concept of closure. | |
874 | * Serial Number:: Example 1: a serial number generator. | |
875 | * Shared Variable:: Example 2: a shared persistent variable. | |
876 | * Callback Closure:: Example 3: the callback closure problem. | |
877 | * OO Closure:: Example 4: object orientation. | |
878 | @end menu | |
879 | ||
880 | @node About Environments | |
881 | @subsection Names, Locations, Values and Environments | |
882 | ||
883 | @cindex location | |
884 | @cindex environment | |
885 | @cindex vcell | |
886 | @cindex top level environment | |
887 | @cindex environment, top level | |
888 | ||
889 | We said earlier that a variable name in a Scheme program is associated | |
890 | with a location in which any kind of Scheme value may be stored. | |
891 | (Incidentally, the term ``vcell'' is often used in Lisp and Scheme | |
892 | circles as an alternative to ``location''.) Thus part of what we mean | |
893 | when we talk about ``creating a variable'' is in fact establishing an | |
894 | association between a name, or identifier, that is used by the Scheme | |
895 | program code, and the variable location to which that name refers. | |
896 | Although the value that is stored in that location may change, the | |
897 | location to which a given name refers is always the same. | |
898 | ||
899 | We can illustrate this by breaking down the operation of the | |
900 | @code{define} syntax into three parts: @code{define} | |
901 | ||
902 | @itemize @bullet | |
903 | @item | |
904 | creates a new location | |
905 | ||
906 | @item | |
907 | establishes an association between that location and the name specified | |
908 | as the first argument of the @code{define} expression | |
909 | ||
910 | @item | |
911 | stores in that location the value obtained by evaluating the second | |
912 | argument of the @code{define} expression. | |
913 | @end itemize | |
914 | ||
915 | A collection of associations between names and locations is called an | |
916 | @dfn{environment}. When you create a top level variable in a program | |
917 | using @code{define}, the name-location association for that variable is | |
918 | added to the ``top level'' environment. The ``top level'' environment | |
919 | also includes name-location associations for all the procedures that are | |
920 | supplied by standard Scheme. | |
921 | ||
922 | It is also possible to create environments other than the top level one, | |
923 | and to create variable bindings, or name-location associations, in those | |
924 | environments. This ability is a key ingredient in the concept of | |
925 | closure; the next subsection shows how it is done. | |
926 | ||
927 | ||
928 | @node Local Variables | |
929 | @subsection Local Variables and Environments | |
930 | ||
931 | @cindex local variable | |
932 | @cindex variable, local | |
933 | @cindex local environment | |
934 | @cindex environment, local | |
935 | ||
936 | We have seen how to create top level variables using the @code{define} | |
937 | syntax (@pxref{Definition}). It is often useful to create variables | |
938 | that are more limited in their scope, typically as part of a procedure | |
939 | body. In Scheme, this is done using the @code{let} syntax, or one of | |
940 | its modified forms @code{let*} and @code{letrec}. These syntaxes are | |
941 | described in full later in the manual (@pxref{Local Bindings}). Here | |
942 | our purpose is to illustrate their use just enough that we can see how | |
943 | local variables work. | |
944 | ||
945 | For example, the following code uses a local variable @code{s} to | |
946 | simplify the computation of the area of a triangle given the lengths of | |
947 | its three sides. | |
948 | ||
949 | @lisp | |
950 | (define a 5.3) | |
951 | (define b 4.7) | |
952 | (define c 2.8) | |
953 | ||
954 | (define area | |
955 | (let ((s (/ (+ a b c) 2))) | |
956 | (sqrt (* s (- s a) (- s b) (- s c))))) | |
957 | @end lisp | |
958 | ||
959 | The effect of the @code{let} expression is to create a new environment | |
960 | and, within this environment, an association between the name @code{s} | |
961 | and a new location whose initial value is obtained by evaluating | |
962 | @code{(/ (+ a b c) 2)}. The expressions in the body of the @code{let}, | |
963 | namely @code{(sqrt (* s (- s a) (- s b) (- s c)))}, are then evaluated | |
964 | in the context of the new environment, and the value of the last | |
965 | expression evaluated becomes the value of the whole @code{let} | |
966 | expression, and therefore the value of the variable @code{area}. | |
967 | ||
968 | ||
969 | @node Chaining | |
970 | @subsection Environment Chaining | |
971 | ||
972 | @cindex shadowing an imported variable binding | |
973 | @cindex chaining environments | |
974 | ||
975 | In the example of the previous subsection, we glossed over an important | |
976 | point. The body of the @code{let} expression in that example refers not | |
977 | only to the local variable @code{s}, but also to the top level variables | |
978 | @code{a}, @code{b}, @code{c} and @code{sqrt}. (@code{sqrt} is the | |
979 | standard Scheme procedure for calculating a square root.) If the body | |
980 | of the @code{let} expression is evaluated in the context of the | |
981 | @emph{local} @code{let} environment, how does the evaluation get at the | |
982 | values of these top level variables? | |
983 | ||
984 | The answer is that the local environment created by a @code{let} | |
985 | expression automatically has a reference to its containing environment | |
986 | --- in this case the top level environment --- and that the Scheme | |
987 | interpreter automatically looks for a variable binding in the containing | |
988 | environment if it doesn't find one in the local environment. More | |
989 | generally, every environment except for the top level one has a | |
990 | reference to its containing environment, and the interpreter keeps | |
991 | searching back up the chain of environments --- from most local to top | |
992 | level --- until it either finds a variable binding for the required | |
993 | identifier or exhausts the chain. | |
994 | ||
995 | This description also determines what happens when there is more than | |
996 | one variable binding with the same name. Suppose, continuing the | |
997 | example of the previous subsection, that there was also a pre-existing | |
998 | top level variable @code{s} created by the expression: | |
999 | ||
1000 | @lisp | |
1001 | (define s "Some beans, my lord!") | |
1002 | @end lisp | |
1003 | ||
1004 | Then both the top level environment and the local @code{let} environment | |
1005 | would contain bindings for the name @code{s}. When evaluating code | |
1006 | within the @code{let} body, the interpreter looks first in the local | |
1007 | @code{let} environment, and so finds the binding for @code{s} created by | |
1008 | the @code{let} syntax. Even though this environment has a reference to | |
1009 | the top level environment, which also has a binding for @code{s}, the | |
1010 | interpreter doesn't get as far as looking there. When evaluating code | |
1011 | outside the @code{let} body, the interpreter looks up variable names in | |
1012 | the top level environment, so the name @code{s} refers to the top level | |
1013 | variable. | |
1014 | ||
1015 | Within the @code{let} body, the binding for @code{s} in the local | |
1016 | environment is said to @dfn{shadow} the binding for @code{s} in the top | |
1017 | level environment. | |
1018 | ||
1019 | ||
1020 | @node Lexical Scope | |
1021 | @subsection Lexical Scope | |
1022 | ||
1023 | The rules that we have just been describing are the details of how | |
1024 | Scheme implements ``lexical scoping''. This subsection takes a brief | |
1025 | diversion to explain what lexical scope means in general and to present | |
1026 | an example of non-lexical scoping. | |
1027 | ||
1028 | ``Lexical scope'' in general is the idea that | |
1029 | ||
1030 | @itemize @bullet | |
1031 | @item | |
1032 | an identifier at a particular place in a program always refers to the | |
1033 | same variable location --- where ``always'' means ``every time that the | |
1034 | containing expression is executed'', and that | |
1035 | ||
1036 | @item | |
1037 | the variable location to which it refers can be determined by static | |
1038 | examination of the source code context in which that identifier appears, | |
1039 | without having to consider the flow of execution through the program as | |
1040 | a whole. | |
1041 | @end itemize | |
1042 | ||
1043 | In practice, lexical scoping is the norm for most programming languages, | |
1044 | and probably corresponds to what you would intuitively consider to be | |
1045 | ``normal''. You may even be wondering how the situation could possibly | |
1046 | --- and usefully --- be otherwise. To demonstrate that another kind of | |
1047 | scoping is possible, therefore, and to compare it against lexical | |
1048 | scoping, the following subsection presents an example of non-lexical | |
1049 | scoping and examines in detail how its behavior differs from the | |
1050 | corresponding lexically scoped code. | |
1051 | ||
1052 | @menu | |
1053 | * Scoping Example:: An example of non-lexical scoping. | |
1054 | @end menu | |
1055 | ||
1056 | ||
1057 | @node Scoping Example | |
1058 | @subsubsection An Example of Non-Lexical Scoping | |
1059 | ||
1060 | To demonstrate that non-lexical scoping does exist and can be useful, we | |
1061 | present the following example from Emacs Lisp, which is a ``dynamically | |
1062 | scoped'' language. | |
1063 | ||
1064 | @lisp | |
1065 | (defvar currency-abbreviation "USD") | |
1066 | ||
1067 | (defun currency-string (units hundredths) | |
1068 | (concat currency-abbreviation | |
1069 | (number-to-string units) | |
1070 | "." | |
1071 | (number-to-string hundredths))) | |
1072 | ||
1073 | (defun french-currency-string (units hundredths) | |
1074 | (let ((currency-abbreviation "FRF")) | |
1075 | (currency-string units hundredths))) | |
1076 | @end lisp | |
1077 | ||
1078 | The question to focus on here is: what does the identifier | |
1079 | @code{currency-abbreviation} refer to in the @code{currency-string} | |
1080 | function? The answer, in Emacs Lisp, is that all variable bindings go | |
1081 | onto a single stack, and that @code{currency-abbreviation} refers to the | |
1082 | topmost binding from that stack which has the name | |
1083 | ``currency-abbreviation''. The binding that is created by the | |
1084 | @code{defvar} form, to the value @code{"USD"}, is only relevant if none | |
1085 | of the code that calls @code{currency-string} rebinds the name | |
1086 | ``currency-abbreviation'' in the meanwhile. | |
1087 | ||
1088 | The second function @code{french-currency-string} works precisely by | |
1089 | taking advantage of this behaviour. It creates a new binding for the | |
1090 | name ``currency-abbreviation'' which overrides the one established by | |
1091 | the @code{defvar} form. | |
1092 | ||
1093 | @lisp | |
1094 | ;; Note! This is Emacs Lisp evaluation, not Scheme! | |
1095 | (french-currency-string 33 44) | |
1096 | @result{} | |
1097 | "FRF33.44" | |
1098 | @end lisp | |
1099 | ||
1100 | Now let's look at the corresponding, @emph{lexically scoped} Scheme | |
1101 | code: | |
1102 | ||
1103 | @lisp | |
1104 | (define currency-abbreviation "USD") | |
1105 | ||
1106 | (define (currency-string units hundredths) | |
1107 | (string-append currency-abbreviation | |
1108 | (number->string units) | |
1109 | "." | |
1110 | (number->string hundredths))) | |
1111 | ||
1112 | (define (french-currency-string units hundredths) | |
1113 | (let ((currency-abbreviation "FRF")) | |
1114 | (currency-string units hundredths))) | |
1115 | @end lisp | |
1116 | ||
1117 | According to the rules of lexical scoping, the | |
1118 | @code{currency-abbreviation} in @code{currency-string} refers to the | |
1119 | variable location in the innermost environment at that point in the code | |
1120 | which has a binding for @code{currency-abbreviation}, which is the | |
1121 | variable location in the top level environment created by the preceding | |
1122 | @code{(define currency-abbreviation @dots{})} expression. | |
1123 | ||
1124 | In Scheme, therefore, the @code{french-currency-string} procedure does | |
1125 | not work as intended. The variable binding that it creates for | |
1126 | ``currency-abbreviation'' is purely local to the code that forms the | |
1127 | body of the @code{let} expression. Since this code doesn't directly use | |
1128 | the name ``currency-abbreviation'' at all, the binding is pointless. | |
1129 | ||
1130 | @lisp | |
1131 | (french-currency-string 33 44) | |
1132 | @result{} | |
1133 | "USD33.44" | |
1134 | @end lisp | |
1135 | ||
1136 | This begs the question of how the Emacs Lisp behaviour can be | |
1137 | implemented in Scheme. In general, this is a design question whose | |
1138 | answer depends upon the problem that is being addressed. In this case, | |
1139 | the best answer may be that @code{currency-string} should be | |
1140 | redesigned so that it can take an optional third argument. This third | |
1141 | argument, if supplied, is interpreted as a currency abbreviation that | |
1142 | overrides the default. | |
1143 | ||
1144 | It is possible to change @code{french-currency-string} so that it mostly | |
1145 | works without changing @code{currency-string}, but the fix is inelegant, | |
1146 | and susceptible to interrupts that could leave the | |
1147 | @code{currency-abbreviation} variable in the wrong state: | |
1148 | ||
1149 | @lisp | |
1150 | (define (french-currency-string units hundredths) | |
1151 | (set! currency-abbreviation "FRF") | |
1152 | (let ((result (currency-string units hundredths))) | |
1153 | (set! currency-abbreviation "USD") | |
1154 | result)) | |
1155 | @end lisp | |
1156 | ||
1157 | The key point here is that the code does not create any local binding | |
1158 | for the identifier @code{currency-abbreviation}, so all occurences of | |
1159 | this identifier refer to the top level variable. | |
1160 | ||
1161 | ||
1162 | @node Closure | |
1163 | @subsection Closure | |
1164 | ||
1165 | Consider a @code{let} expression that doesn't contain any | |
1166 | @code{lambda}s: | |
1167 | ||
1168 | @lisp | |
1169 | (let ((s (/ (+ a b c) 2))) | |
1170 | (sqrt (* s (- s a) (- s b) (- s c)))) | |
1171 | @end lisp | |
1172 | ||
1173 | @noindent | |
1174 | When the Scheme interpreter evaluates this, it | |
1175 | ||
1176 | @itemize @bullet | |
1177 | @item | |
1178 | creates a new environment with a reference to the environment that was | |
1179 | current when it encountered the @code{let} | |
1180 | ||
1181 | @item | |
1182 | creates a variable binding for @code{s} in the new environment, with | |
1183 | value given by @code{(/ (+ a b c) 2)} | |
1184 | ||
1185 | @item | |
1186 | evaluates the expression in the body of the @code{let} in the context of | |
1187 | the new local environment, and remembers the value @code{V} | |
1188 | ||
1189 | @item | |
1190 | forgets the local environment | |
1191 | ||
1192 | @item | |
1193 | continues evaluating the expression that contained the @code{let}, using | |
1194 | the value @code{V} as the value of the @code{let} expression, in the | |
1195 | context of the containing environment. | |
1196 | @end itemize | |
1197 | ||
1198 | After the @code{let} expression has been evaluated, the local | |
1199 | environment that was created is simply forgotten, and there is no longer | |
1200 | any way to access the binding that was created in this environment. If | |
1201 | the same code is evaluated again, it will follow the same steps again, | |
1202 | creating a second new local environment that has no connection with the | |
1203 | first, and then forgetting this one as well. | |
1204 | ||
1205 | If the @code{let} body contains a @code{lambda} expression, however, the | |
1206 | local environment is @emph{not} forgotten. Instead, it becomes | |
1207 | associated with the procedure that is created by the @code{lambda} | |
1208 | expression, and is reinstated every time that that procedure is called. | |
1209 | In detail, this works as follows. | |
1210 | ||
1211 | @itemize @bullet | |
1212 | @item | |
1213 | When the Scheme interpreter evaluates a @code{lambda} expression, to | |
1214 | create a procedure object, it stores the current environment as part of | |
1215 | the procedure definition. | |
1216 | ||
1217 | @item | |
1218 | Then, whenever that procedure is called, the interpreter reinstates the | |
1219 | environment that is stored in the procedure definition and evaluates the | |
1220 | procedure body within the context of that environment. | |
1221 | @end itemize | |
1222 | ||
1223 | The result is that the procedure body is always evaluated in the context | |
1224 | of the environment that was current when the procedure was created. | |
1225 | ||
1226 | This is what is meant by @dfn{closure}. The next few subsections | |
1227 | present examples that explore the usefulness of this concept. | |
1228 | ||
1229 | ||
1230 | @node Serial Number | |
1231 | @subsection Example 1: A Serial Number Generator | |
1232 | ||
1233 | This example uses closure to create a procedure with a variable binding | |
1234 | that is private to the procedure, like a local variable, but whose value | |
1235 | persists between procedure calls. | |
1236 | ||
1237 | @lisp | |
1238 | (define (make-serial-number-generator) | |
1239 | (let ((current-serial-number 0)) | |
1240 | (lambda () | |
1241 | (set! current-serial-number (+ current-serial-number 1)) | |
1242 | current-serial-number))) | |
1243 | ||
1244 | (define entry-sn-generator (make-serial-number-generator)) | |
1245 | ||
1246 | (entry-sn-generator) | |
1247 | @result{} | |
1248 | 1 | |
1249 | ||
1250 | (entry-sn-generator) | |
1251 | @result{} | |
1252 | 2 | |
1253 | @end lisp | |
1254 | ||
1255 | When @code{make-serial-number-generator} is called, it creates a local | |
1256 | environment with a binding for @code{current-serial-number} whose | |
1257 | initial value is 0, then, within this environment, creates a procedure. | |
1258 | The local environment is stored within the created procedure object and | |
1259 | so persists for the lifetime of the created procedure. | |
1260 | ||
1261 | Every time the created procedure is invoked, it increments the value of | |
1262 | the @code{current-serial-number} binding in the captured environment and | |
1263 | then returns the current value. | |
1264 | ||
1265 | Note that @code{make-serial-number-generator} can be called again to | |
1266 | create a second serial number generator that is independent of the | |
1267 | first. Every new invocation of @code{make-serial-number-generator} | |
1268 | creates a new local @code{let} environment and returns a new procedure | |
1269 | object with an association to this environment. | |
1270 | ||
1271 | ||
1272 | @node Shared Variable | |
1273 | @subsection Example 2: A Shared Persistent Variable | |
1274 | ||
1275 | This example uses closure to create two procedures, @code{get-balance} | |
1276 | and @code{deposit}, that both refer to the same captured local | |
1277 | environment so that they can both access the @code{balance} variable | |
1278 | binding inside that environment. The value of this variable binding | |
1279 | persists between calls to either procedure. | |
1280 | ||
1281 | Note that the captured @code{balance} variable binding is private to | |
1282 | these two procedures: it is not directly accessible to any other code. | |
1283 | It can only be accessed indirectly via @code{get-balance} or | |
1284 | @code{deposit}, as illustrated by the @code{withdraw} procedure. | |
1285 | ||
1286 | @lisp | |
1287 | (define get-balance #f) | |
1288 | (define deposit #f) | |
1289 | ||
1290 | (let ((balance 0)) | |
1291 | (set! get-balance | |
1292 | (lambda () | |
1293 | balance)) | |
1294 | (set! deposit | |
1295 | (lambda (amount) | |
1296 | (set! balance (+ balance amount)) | |
1297 | balance))) | |
1298 | ||
1299 | (define (withdraw amount) | |
1300 | (deposit (- amount))) | |
1301 | ||
1302 | (get-balance) | |
1303 | @result{} | |
1304 | 0 | |
1305 | ||
1306 | (deposit 50) | |
1307 | @result{} | |
1308 | 50 | |
1309 | ||
1310 | (withdraw 75) | |
1311 | @result{} | |
1312 | -25 | |
1313 | @end lisp | |
1314 | ||
1315 | A detail here is that the @code{get-balance} and @code{deposit} | |
1316 | variables must be set up by @code{define}ing them at top level and then | |
1317 | @code{set!}ing their values inside the @code{let} body. Using | |
1318 | @code{define} within the @code{let} body would not work: this would | |
1319 | create variable bindings within the local @code{let} environment that | |
1320 | would not be accessible at top level. | |
1321 | ||
1322 | ||
1323 | @node Callback Closure | |
1324 | @subsection Example 3: The Callback Closure Problem | |
1325 | ||
1326 | A frequently used programming model for library code is to allow an | |
1327 | application to register a callback function for the library to call when | |
1328 | some particular event occurs. It is often useful for the application to | |
1329 | make several such registrations using the same callback function, for | |
1330 | example if several similar library events can be handled using the same | |
1331 | application code, but the need then arises to distinguish the callback | |
1332 | function calls that are associated with one callback registration from | |
1333 | those that are associated with different callback registrations. | |
1334 | ||
1335 | In languages without the ability to create functions dynamically, this | |
1336 | problem is usually solved by passing a @code{user_data} parameter on the | |
1337 | registration call, and including the value of this parameter as one of | |
1338 | the parameters on the callback function. Here is an example of | |
1339 | declarations using this solution in C: | |
1340 | ||
1341 | @example | |
1342 | typedef void (event_handler_t) (int event_type, | |
1343 | void *user_data); | |
1344 | ||
1345 | void register_callback (int event_type, | |
1346 | event_handler_t *handler, | |
1347 | void *user_data); | |
1348 | @end example | |
1349 | ||
1350 | In Scheme, closure can be used to achieve the same functionality without | |
1351 | requiring the library code to store a @code{user-data} for each callback | |
1352 | registration. | |
1353 | ||
1354 | @lisp | |
1355 | ;; In the library: | |
1356 | ||
1357 | (define (register-callback event-type handler-proc) | |
1358 | @dots{}) | |
1359 | ||
1360 | ;; In the application: | |
1361 | ||
1362 | (define (make-handler event-type user-data) | |
1363 | (lambda () | |
1364 | @dots{} | |
1365 | <code referencing event-type and user-data> | |
1366 | @dots{})) | |
1367 | ||
1368 | (register-callback event-type | |
1369 | (make-handler event-type @dots{})) | |
1370 | @end lisp | |
1371 | ||
1372 | As far as the library is concerned, @code{handler-proc} is a procedure | |
1373 | with no arguments, and all the library has to do is call it when the | |
1374 | appropriate event occurs. From the application's point of view, though, | |
1375 | the handler procedure has used closure to capture an environment that | |
1376 | includes all the context that the handler code needs --- | |
1377 | @code{event-type} and @code{user-data} --- to handle the event | |
1378 | correctly. | |
1379 | ||
1380 | ||
1381 | @node OO Closure | |
1382 | @subsection Example 4: Object Orientation | |
1383 | ||
1384 | Closure is the capture of an environment, containing persistent variable | |
1385 | bindings, within the definition of a procedure or a set of related | |
1386 | procedures. This is rather similar to the idea in some object oriented | |
1387 | languages of encapsulating a set of related data variables inside an | |
1388 | ``object'', together with a set of ``methods'' that operate on the | |
1389 | encapsulated data. The following example shows how closure can be used | |
1390 | to emulate the ideas of objects, methods and encapsulation in Scheme. | |
1391 | ||
1392 | @lisp | |
1393 | (define (make-account) | |
1394 | (let ((balance 0)) | |
1395 | (define (get-balance) | |
1396 | balance) | |
1397 | (define (deposit amount) | |
1398 | (set! balance (+ balance amount)) | |
1399 | balance) | |
1400 | (define (withdraw amount) | |
1401 | (deposit (- amount))) | |
1402 | ||
1403 | (lambda args | |
1404 | (apply | |
1405 | (case (car args) | |
1406 | ((get-balance) get-balance) | |
1407 | ((deposit) deposit) | |
1408 | ((withdraw) withdraw) | |
1409 | (else (error "Invalid method!"))) | |
1410 | (cdr args))))) | |
1411 | @end lisp | |
1412 | ||
1413 | Each call to @code{make-account} creates and returns a new procedure, | |
1414 | created by the expression in the example code that begins ``(lambda | |
1415 | args''. | |
1416 | ||
1417 | @lisp | |
1418 | (define my-account (make-account)) | |
1419 | ||
1420 | my-account | |
1421 | @result{} | |
1422 | #<procedure args> | |
1423 | @end lisp | |
1424 | ||
1425 | This procedure acts as an account object with methods | |
1426 | @code{get-balance}, @code{deposit} and @code{withdraw}. To apply one of | |
1427 | the methods to the account, you call the procedure with a symbol | |
1428 | indicating the required method as the first parameter, followed by any | |
1429 | other parameters that are required by that method. | |
1430 | ||
1431 | @lisp | |
1432 | (my-account 'get-balance) | |
1433 | @result{} | |
1434 | 0 | |
1435 | ||
1436 | (my-account 'withdraw 5) | |
1437 | @result{} | |
1438 | -5 | |
1439 | ||
1440 | (my-account 'deposit 396) | |
1441 | @result{} | |
1442 | 391 | |
1443 | ||
1444 | (my-account 'get-balance) | |
1445 | @result{} | |
1446 | 391 | |
1447 | @end lisp | |
1448 | ||
1449 | Note how, in this example, both the current balance and the helper | |
1450 | procedures @code{get-balance}, @code{deposit} and @code{withdraw}, used | |
1451 | to implement the guts of the account object's methods, are all stored in | |
1452 | variable bindings within the private local environment captured by the | |
1453 | @code{lambda} expression that creates the account object procedure. | |
1454 | ||
1455 | ||
1456 | @c Local Variables: | |
1457 | @c TeX-master: "guile.texi" | |
1458 | @c End: |