3 @chapter Basic Ideas in Scheme
5 In this chapter, we introduce the basic concepts that underpin the
6 elegance and power of the Scheme language.
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.
14 The style of this introductory material aims about halfway between the
15 terse precision of R5RS and the discursive randomness of a Scheme
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.
27 @section Data Types, Values and Variables
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
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.
43 @subsection Latent Typing
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.
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.
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
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.
75 The next subsection explains what this means in practice, for the ways
76 that Scheme programs use data types, values and variables.
79 @node Values and Variables
80 @subsection Values and Variables
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.
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.
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
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,
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.
117 @subsection Defining and Setting Variables
119 To define a new variable, you use Scheme's @code{define} syntax like
123 (define @var{variable-name} @var{value})
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:
130 ;; Make a variable `x' with initial numeric value 1.
133 ;; Make a variable `organization' with an initial string value.
134 (define organization "Free Software Foundation")
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
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!},
146 (set! @var{variable-name} @var{new-value})
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.
155 ;; Change the value of `x' to 5.
158 ;; Change the value of `organization' to the FSF's street number.
159 (set! organization 545)
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{}
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
181 @ref{Lambda Alternatives}, to read about an alternative form of the
182 @code{define} syntax that can be used when defining new procedures.
185 @ref{Procedures with Setters}, to read about an alternative form of the
186 @code{set!} syntax that helps with changing a single value in the depths
187 of a compound data structure.)
190 @xref{Internal Definitions}, to read about using @code{define} other
191 than at top level in a Scheme program, including a discussion of when it
192 works to use @code{define} rather than @code{set!} to change the value
193 of an existing variable.
197 @node About Procedures
198 @section The Representation and Use of Procedures
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.
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.
216 @node Procedures as Values
217 @subsection Procedures as Values
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.
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}.
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.
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
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}.
250 (define call/cc call-with-current-continuation)
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.
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:
267 (set! call-with-current-continuation "Not a procedure any more!")
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
275 @node Simple Invocation
276 @subsection Simple Procedure Invocation
278 A procedure invocation in Scheme is written like this:
281 (@var{procedure} [@var{arg1} [@var{arg2} @dots{}]])
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.
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
293 (string-append "/home" "/" "andrew")
297 is a procedure invocation whose result is the string value
298 @code{"/home/andrew"}.
300 Similarly, @code{string-length} is a standard Scheme procedure that
301 returns the length of a single string argument, so
304 (string-length "abc")
308 is a procedure invocation whose result is the numeric value 3.
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
315 (string-length (string-append "/home" "/" "andrew"))
319 --- a procedure invocation whose result is the numeric value 12.
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:
326 (string-append "/home" (string-length "abc"))
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
336 @node Creating a Procedure
337 @subsection Creating and Using a New Procedure
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.
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.
347 For example, the value of the following Scheme expression
350 (lambda (name address) @var{expression} @dots{})
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.
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:
369 (lambda (name address)
370 (string-append "Name=" name ":Address=" address))
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
380 ((lambda (name address)
381 (string-append "Name=" name ":Address=" address))
387 This is a valid procedure invocation expression, and its result is the
388 string @code{"Name=FSF:Address=Cambridge"}.
390 It it more common, though, to store the procedure value in a variable ---
393 (define make-combined-string
394 (lambda (name address)
395 (string-append "Name=" name ":Address=" address)))
399 --- and then to use the variable name in the procedure invocation:
402 (make-combined-string "FSF" "Cambridge")
406 Which has exactly the same result.
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
414 @node Lambda Alternatives
415 @subsection Lambda Alternatives
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.
421 A @code{define} expression of the form
424 (define (@var{name} [@var{arg1} [@var{arg2} @dots{}]])
425 @var{expression} @dots{})
429 is exactly equivalent to the longer form
433 (lambda ([@var{arg1} [@var{arg2} @dots{}]])
434 @var{expression} @dots{}))
437 So, for example, the definition of @code{make-combined-string} in the
438 previous subsection could equally be written:
441 (define (make-combined-string name address)
442 (string-append "Name=" name ":Address=" address))
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:
451 (lambda (@var{arg1} @dots{} . @var{args}) @var{expression} @dots{})
453 (lambda @var{args} @var{expression} @dots{})
457 The corresponding forms of the alternative @code{define} syntax are:
460 (define (@var{name} @var{arg1} @dots{} . @var{args}) @var{expression} @dots{})
462 (define (@var{name} . @var{args}) @var{expression} @dots{})
466 For details on how these forms work, see @xref{Lambda}.
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.)
478 @node About Expressions
479 @section Expressions and Evaluation
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:
487 (string-append "/home" "/" "andrew")
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
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
505 * Evaluating:: How a Scheme program is executed.
506 * The REPL:: Interacting with the Guile interpreter.
507 * Syntax Summary:: Common syntactic expressions -- in brief.
512 @subsection Evaluating Expressions and Executing Programs
514 In Scheme, the process of executing an expression is known as
515 @dfn{evaluation}. Evaluation has two kinds of result:
519 the @dfn{value} of the evaluated expression
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.
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.
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.
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{}
549 A Scheme program consists of a sequence of expressions.
552 A Scheme interpreter executes the program by evaluating these
553 expressions in order, one by one.
560 a piece of literal data, such as a number @code{2.3} or a string
561 @code{"Hello world!"}
565 a procedure invocation expression
567 one of Scheme's special syntactic expressions.
572 The following subsections describe how each of these types of expression
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.
583 @subsubsection Evaluating Literal Data
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.
594 the value of the expression @code{"abc"} is the string value
598 the value of the expression @code{3+4i} is the complex number 3 + 4i
601 the value of the expression @code{#(1 2 3)} is a three-element vector
602 containing the numeric values 1, 2 and 3.
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.
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}).
619 @subsubsection Evaluating a Variable Reference
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.
628 (define key "Paul Evans")
632 the value of the expression @code{key} is the string value @code{"Paul
633 Evans"}. If @var{key} is then modified by
640 the value of the expression @code{key} is the numeric value 3.74.
642 If there is no variable with the specified name, evaluation of the
643 variable reference expression signals an error.
647 @subsubsection Evaluating a Procedure Invocation Expression
649 This is where evaluation starts getting interesting! As already noted,
650 a procedure invocation expression has the form
653 (@var{procedure} [@var{arg1} [@var{arg2} @dots{}]])
657 where @var{procedure} must be an expression whose value, when evaluated,
660 The evaluation of a procedure invocation expression like this proceeds
665 evaluating individually the expressions @var{procedure}, @var{arg1},
666 @var{arg2}, and so on
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.
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.
683 For a built-in procedure, the value and side-effects of calling the
684 procedure are best described by that procedure's documentation.
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.
691 To illustrate this, let's look again at the procedure invocation
695 (string-length (string-append "/home" "/" "andrew"))
698 In the outermost expression, @var{procedure} is @code{string-length} and
699 @var{arg1} is @code{(string-append "/home" "/" "andrew")}.
703 Evaluation of @code{string-length}, which is a variable, gives a
704 procedure value that implements the expected behaviour for
708 Evaluation of @code{(string-append "/home" "/" "andrew")}, which is
709 another procedure invocation expression, means evaluating each of
713 @code{string-append}, which gives a procedure value that implements the
714 expected behaviour for ``string-append''
717 @code{"/home"}, which gives the string value @code{"/home"}
720 @code{"/"}, which gives the string value @code{"/"}
723 @code{"andrew"}, which gives the string value @code{"andrew"}
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"}.
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.
738 @subsubsection Evaluating Special Syntactic Expressions
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
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
752 (if (string=? (read-answer "Should I delete this file?")
757 If the outermost @code{(if @dots{})} expression here was a procedure
758 invocation expression, the expression @code{(delete-file file)}, whose
759 side effect is to actually delete a file, would already have been
760 evaluated before the @code{if} procedure even got invoked! Clearly this
761 is no use --- 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''.
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.
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}.
782 @subsection Using the Guile REPL
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
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.
796 In this manual, the notation @result{} is used to mean ``evaluates
797 to''. Wherever you see an example of the form
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}.
811 @subsection Summary of Common Syntax
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.
818 @code{lambda} (@pxref{Lambda}) is used to construct procedure objects.
820 @code{define} (@pxref{Top Level}) is used to create a new variable and
821 set its initial value.
823 @code{set!} (@pxref{Top Level}) is used to modify an existing variable's
826 @code{let}, @code{let*} and @code{letrec} (@pxref{Local Bindings})
827 create an inner lexical environment for the evaluation of a sequence of
828 expressions, in which a specified set of local variables is bound to the
829 values of a corresponding set of expressions. For an introduction to
830 environments, see @xref{About Closure}.
832 @code{begin} (@pxref{begin}) executes a sequence of expressions in order
833 and returns the value of the last expression. Note that this is not the
834 same as a procedure which returns its last argument, because the
835 evaluation of a procedure invocation expression does not guarantee to
836 evaluate the arguments in order.
838 @code{if} and @code{cond} (@pxref{if cond case}) provide conditional
839 evaluation of argument expressions depending on whether one or more
840 conditions evaluate to ``true'' or ``false''.
842 @code{case} (@pxref{if cond case}) provides conditional evaluation of
843 argument expressions depending on whether a variable has one of a
844 specified group of values.
846 @code{and} (@pxref{and or}) executes a sequence of expressions in order
847 until either there are no expressions left, or one of them evaluates to
850 @code{or} (@pxref{and or}) executes a sequence of expressions in order
851 until either there are no expressions left, or one of them evaluates to
856 @section The Concept of Closure
860 The concept of @dfn{closure} is the idea that a lambda expression
861 ``captures'' the variable bindings that are in lexical scope at the
862 point where the lambda expression occurs. The procedure created by the
863 lambda expression can refer to and mutate the captured bindings, and the
864 values of those bindings persist between procedure calls.
866 This section explains and explores the various parts of this idea in
870 * About Environments:: Names, locations, values and environments.
871 * Local Variables:: Local variables and local environments.
872 * Chaining:: Environment chaining.
873 * Lexical Scope:: The meaning of lexical scoping.
874 * Closure:: Explaining the concept of closure.
875 * Serial Number:: Example 1: a serial number generator.
876 * Shared Variable:: Example 2: a shared persistent variable.
877 * Callback Closure:: Example 3: the callback closure problem.
878 * OO Closure:: Example 4: object orientation.
881 @node About Environments
882 @subsection Names, Locations, Values and Environments
887 @cindex top level environment
888 @cindex environment, top level
890 We said earlier that a variable name in a Scheme program is associated
891 with a location in which any kind of Scheme value may be stored.
892 (Incidentally, the term ``vcell'' is often used in Lisp and Scheme
893 circles as an alternative to ``location''.) Thus part of what we mean
894 when we talk about ``creating a variable'' is in fact establishing an
895 association between a name, or identifier, that is used by the Scheme
896 program code, and the variable location to which that name refers.
897 Although the value that is stored in that location may change, the
898 location to which a given name refers is always the same.
900 We can illustrate this by breaking down the operation of the
901 @code{define} syntax into three parts: @code{define}
905 creates a new location
908 establishes an association between that location and the name specified
909 as the first argument of the @code{define} expression
912 stores in that location the value obtained by evaluating the second
913 argument of the @code{define} expression.
916 A collection of associations between names and locations is called an
917 @dfn{environment}. When you create a top level variable in a program
918 using @code{define}, the name-location association for that variable is
919 added to the ``top level'' environment. The ``top level'' environment
920 also includes name-location associations for all the procedures that are
921 supplied by standard Scheme.
923 It is also possible to create environments other than the top level one,
924 and to create variable bindings, or name-location associations, in those
925 environments. This ability is a key ingredient in the concept of
926 closure; the next subsection shows how it is done.
929 @node Local Variables
930 @subsection Local Variables and Environments
932 @cindex local variable
933 @cindex variable, local
934 @cindex local environment
935 @cindex environment, local
937 We have seen how to create top level variables using the @code{define}
938 syntax (@pxref{Definition}). It is often useful to create variables
939 that are more limited in their scope, typically as part of a procedure
940 body. In Scheme, this is done using the @code{let} syntax, or one of
941 its modified forms @code{let*} and @code{letrec}. These syntaxes are
942 described in full later in the manual (@pxref{Local Bindings}). Here
943 our purpose is to illustrate their use just enough that we can see how
944 local variables work.
946 For example, the following code uses a local variable @code{s} to
947 simplify the computation of the area of a triangle given the lengths of
956 (let ((s (/ (+ a b c) 2)))
957 (sqrt (* s (- s a) (- s b) (- s c)))))
960 The effect of the @code{let} expression is to create a new environment
961 and, within this environment, an association between the name @code{s}
962 and a new location whose initial value is obtained by evaluating
963 @code{(/ (+ a b c) 2)}. The expressions in the body of the @code{let},
964 namely @code{(sqrt (* s (- s a) (- s b) (- s c)))}, are then evaluated
965 in the context of the new environment, and the value of the last
966 expression evaluated becomes the value of the whole @code{let}
967 expression, and therefore the value of the variable @code{area}.
971 @subsection Environment Chaining
973 @cindex shadowing an imported variable binding
974 @cindex chaining environments
976 In the example of the previous subsection, we glossed over an important
977 point. The body of the @code{let} expression in that example refers not
978 only to the local variable @code{s}, but also to the top level variables
979 @code{a}, @code{b}, @code{c} and @code{sqrt}. (@code{sqrt} is the
980 standard Scheme procedure for calculating a square root.) If the body
981 of the @code{let} expression is evaluated in the context of the
982 @emph{local} @code{let} environment, how does the evaluation get at the
983 values of these top level variables?
985 The answer is that the local environment created by a @code{let}
986 expression automatically has a reference to its containing environment
987 --- in this case the top level environment --- and that the Scheme
988 interpreter automatically looks for a variable binding in the containing
989 environment if it doesn't find one in the local environment. More
990 generally, every environment except for the top level one has a
991 reference to its containing environment, and the interpreter keeps
992 searching back up the chain of environments --- from most local to top
993 level --- until it either finds a variable binding for the required
994 identifier or exhausts the chain.
996 This description also determines what happens when there is more than
997 one variable binding with the same name. Suppose, continuing the
998 example of the previous subsection, that there was also a pre-existing
999 top level variable @code{s} created by the expression:
1002 (define s "Some beans, my lord!")
1005 Then both the top level environment and the local @code{let} environment
1006 would contain bindings for the name @code{s}. When evaluating code
1007 within the @code{let} body, the interpreter looks first in the local
1008 @code{let} environment, and so finds the binding for @code{s} created by
1009 the @code{let} syntax. Even though this environment has a reference to
1010 the top level environment, which also has a binding for @code{s}, the
1011 interpreter doesn't get as far as looking there. When evaluating code
1012 outside the @code{let} body, the interpreter looks up variable names in
1013 the top level environment, so the name @code{s} refers to the top level
1016 Within the @code{let} body, the binding for @code{s} in the local
1017 environment is said to @dfn{shadow} the binding for @code{s} in the top
1022 @subsection Lexical Scope
1024 The rules that we have just been describing are the details of how
1025 Scheme implements ``lexical scoping''. This subsection takes a brief
1026 diversion to explain what lexical scope means in general and to present
1027 an example of non-lexical scoping.
1029 ``Lexical scope'' in general is the idea that
1033 an identifier at a particular place in a program always refers to the
1034 same variable location --- where ``always'' means ``every time that the
1035 containing expression is executed'', and that
1038 the variable location to which it refers can be determined by static
1039 examination of the source code context in which that identifier appears,
1040 without having to consider the flow of execution through the program as
1044 In practice, lexical scoping is the norm for most programming languages,
1045 and probably corresponds to what you would intuitively consider to be
1046 ``normal''. You may even be wondering how the situation could possibly
1047 --- and usefully --- be otherwise. To demonstrate that another kind of
1048 scoping is possible, therefore, and to compare it against lexical
1049 scoping, the following subsection presents an example of non-lexical
1050 scoping and examines in detail how its behavior differs from the
1051 corresponding lexically scoped code.
1054 * Scoping Example:: An example of non-lexical scoping.
1058 @node Scoping Example
1059 @subsubsection An Example of Non-Lexical Scoping
1061 To demonstrate that non-lexical scoping does exist and can be useful, we
1062 present the following example from Emacs Lisp, which is a ``dynamically
1066 (defvar currency-abbreviation "USD")
1068 (defun currency-string (units hundredths)
1069 (concat currency-abbreviation
1070 (number-to-string units)
1072 (number-to-string hundredths)))
1074 (defun french-currency-string (units hundredths)
1075 (let ((currency-abbreviation "FRF"))
1076 (currency-string units hundredths)))
1079 The question to focus on here is: what does the identifier
1080 @code{currency-abbreviation} refer to in the @code{currency-string}
1081 function? The answer, in Emacs Lisp, is that all variable bindings go
1082 onto a single stack, and that @code{currency-abbreviation} refers to the
1083 topmost binding from that stack which has the name
1084 ``currency-abbreviation''. The binding that is created by the
1085 @code{defvar} form, to the value @code{"USD"}, is only relevant if none
1086 of the code that calls @code{currency-string} rebinds the name
1087 ``currency-abbreviation'' in the meanwhile.
1089 The second function @code{french-currency-string} works precisely by
1090 taking advantage of this behaviour. It creates a new binding for the
1091 name ``currency-abbreviation'' which overrides the one established by
1092 the @code{defvar} form.
1095 ;; Note! This is Emacs Lisp evaluation, not Scheme!
1096 (french-currency-string 33 44)
1101 Now let's look at the corresponding, @emph{lexically scoped} Scheme
1105 (define currency-abbreviation "USD")
1107 (define (currency-string units hundredths)
1108 (string-append currency-abbreviation
1109 (number->string units)
1111 (number->string hundredths)))
1113 (define (french-currency-string units hundredths)
1114 (let ((currency-abbreviation "FRF"))
1115 (currency-string units hundredths)))
1118 According to the rules of lexical scoping, the
1119 @code{currency-abbreviation} in @code{currency-string} refers to the
1120 variable location in the innermost environment at that point in the code
1121 which has a binding for @code{currency-abbreviation}, which is the
1122 variable location in the top level environment created by the preceding
1123 @code{(define currency-abbreviation @dots{})} expression.
1125 In Scheme, therefore, the @code{french-currency-string} procedure does
1126 not work as intended. The variable binding that it creates for
1127 ``currency-abbreviation'' is purely local to the code that forms the
1128 body of the @code{let} expression. Since this code doesn't directly use
1129 the name ``currency-abbreviation'' at all, the binding is pointless.
1132 (french-currency-string 33 44)
1137 This begs the question of how the Emacs Lisp behaviour can be
1138 implemented in Scheme. In general, this is a design question whose
1139 answer depends upon the problem that is being addressed. In this case,
1140 the best answer may be that @code{currency-string} should be
1141 redesigned so that it can take an optional third argument. This third
1142 argument, if supplied, is interpreted as a currency abbreviation that
1143 overrides the default.
1145 It is possible to change @code{french-currency-string} so that it mostly
1146 works without changing @code{currency-string}, but the fix is inelegant,
1147 and susceptible to interrupts that could leave the
1148 @code{currency-abbreviation} variable in the wrong state:
1151 (define (french-currency-string units hundredths)
1152 (set! currency-abbreviation "FRF")
1153 (let ((result (currency-string units hundredths)))
1154 (set! currency-abbreviation "USD")
1158 The key point here is that the code does not create any local binding
1159 for the identifier @code{currency-abbreviation}, so all occurences of
1160 this identifier refer to the top level variable.
1166 Consider a @code{let} expression that doesn't contain any
1170 (let ((s (/ (+ a b c) 2)))
1171 (sqrt (* s (- s a) (- s b) (- s c))))
1175 When the Scheme interpreter evaluates this, it
1179 creates a new environment with a reference to the environment that was
1180 current when it encountered the @code{let}
1183 creates a variable binding for @code{s} in the new environment, with
1184 value given by @code{(/ (+ a b c) 2)}
1187 evaluates the expression in the body of the @code{let} in the context of
1188 the new local environment, and remembers the value @code{V}
1191 forgets the local environment
1194 continues evaluating the expression that contained the @code{let}, using
1195 the value @code{V} as the value of the @code{let} expression, in the
1196 context of the containing environment.
1199 After the @code{let} expression has been evaluated, the local
1200 environment that was created is simply forgotten, and there is no longer
1201 any way to access the binding that was created in this environment. If
1202 the same code is evaluated again, it will follow the same steps again,
1203 creating a second new local environment that has no connection with the
1204 first, and then forgetting this one as well.
1206 If the @code{let} body contains a @code{lambda} expression, however, the
1207 local environment is @emph{not} forgotten. Instead, it becomes
1208 associated with the procedure that is created by the @code{lambda}
1209 expression, and is reinstated every time that that procedure is called.
1210 In detail, this works as follows.
1214 When the Scheme interpreter evaluates a @code{lambda} expression, to
1215 create a procedure object, it stores the current environment as part of
1216 the procedure definition.
1219 Then, whenever that procedure is called, the interpreter reinstates the
1220 environment that is stored in the procedure definition and evaluates the
1221 procedure body within the context of that environment.
1224 The result is that the procedure body is always evaluated in the context
1225 of the environment that was current when the procedure was created.
1227 This is what is meant by @dfn{closure}. The next few subsections
1228 present examples that explore the usefulness of this concept.
1232 @subsection Example 1: A Serial Number Generator
1234 This example uses closure to create a procedure with a variable binding
1235 that is private to the procedure, like a local variable, but whose value
1236 persists between procedure calls.
1239 (define (make-serial-number-generator)
1240 (let ((current-serial-number 0))
1242 (set! current-serial-number (+ current-serial-number 1))
1243 current-serial-number)))
1245 (define entry-sn-generator (make-serial-number-generator))
1247 (entry-sn-generator)
1251 (entry-sn-generator)
1256 When @code{make-serial-number-generator} is called, it creates a local
1257 environment with a binding for @code{current-serial-number} whose
1258 initial value is 0, then, within this environment, creates a procedure.
1259 The local environment is stored within the created procedure object and
1260 so persists for the lifetime of the created procedure.
1262 Every time the created procedure is invoked, it increments the value of
1263 the @code{current-serial-number} binding in the captured environment and
1264 then returns the current value.
1266 Note that @code{make-serial-number-generator} can be called again to
1267 create a second serial number generator that is independent of the
1268 first. Every new invocation of @code{make-serial-number-generator}
1269 creates a new local @code{let} environment and returns a new procedure
1270 object with an association to this environment.
1273 @node Shared Variable
1274 @subsection Example 2: A Shared Persistent Variable
1276 This example uses closure to create two procedures, @code{get-balance}
1277 and @code{deposit}, that both refer to the same captured local
1278 environment so that they can both access the @code{balance} variable
1279 binding inside that environment. The value of this variable binding
1280 persists between calls to either procedure.
1282 Note that the captured @code{balance} variable binding is private to
1283 these two procedures: it is not directly accessible to any other code.
1284 It can only be accessed indirectly via @code{get-balance} or
1285 @code{deposit}, as illustrated by the @code{withdraw} procedure.
1288 (define get-balance #f)
1297 (set! balance (+ balance amount))
1300 (define (withdraw amount)
1301 (deposit (- amount)))
1316 An important detail here is that the @code{get-balance} and
1317 @code{deposit} variables must be set up by @code{define}ing them at top
1318 level and then @code{set!}ing their values inside the @code{let} body.
1319 Using @code{define} within the @code{let} body would not work: this
1320 would create variable bindings within the local @code{let} environment
1321 that would not be accessible at top level.
1324 @node Callback Closure
1325 @subsection Example 3: The Callback Closure Problem
1327 A frequently used programming model for library code is to allow an
1328 application to register a callback function for the library to call when
1329 some particular event occurs. It is often useful for the application to
1330 make several such registrations using the same callback function, for
1331 example if several similar library events can be handled using the same
1332 application code, but the need then arises to distinguish the callback
1333 function calls that are associated with one callback registration from
1334 those that are associated with different callback registrations.
1336 In languages without the ability to create functions dynamically, this
1337 problem is usually solved by passing a @code{user_data} parameter on the
1338 registration call, and including the value of this parameter as one of
1339 the parameters on the callback function. Here is an example of
1340 declarations using this solution in C:
1343 typedef void (event_handler_t) (int event_type,
1346 void register_callback (int event_type,
1347 event_handler_t *handler,
1351 In Scheme, closure can be used to achieve the same functionality without
1352 requiring the library code to store a @code{user-data} for each callback
1358 (define (register-callback event-type handler-proc)
1361 ;; In the application:
1363 (define (make-handler event-type user-data)
1366 <code referencing event-type and user-data>
1369 (register-callback event-type
1370 (make-handler event-type @dots{}))
1373 As far as the library is concerned, @code{handler-proc} is a procedure
1374 with no arguments, and all the library has to do is call it when the
1375 appropriate event occurs. From the application's point of view, though,
1376 the handler procedure has used closure to capture an environment that
1377 includes all the context that the handler code needs ---
1378 @code{event-type} and @code{user-data} --- to handle the event
1383 @subsection Example 4: Object Orientation
1385 Closure is the capture of an environment, containing persistent variable
1386 bindings, within the definition of a procedure or a set of related
1387 procedures. This is rather similar to the idea in some object oriented
1388 languages of encapsulating a set of related data variables inside an
1389 ``object'', together with a set of ``methods'' that operate on the
1390 encapsulated data. The following example shows how closure can be used
1391 to emulate the ideas of objects, methods and encapsulation in Scheme.
1394 (define (make-account)
1396 (define (get-balance)
1398 (define (deposit amount)
1399 (set! balance (+ balance amount))
1401 (define (withdraw amount)
1402 (deposit (- amount)))
1407 ((get-balance) get-balance)
1409 ((withdraw) withdraw)
1410 (else (error "Invalid method!")))
1414 Each call to @code{make-account} creates and returns a new procedure,
1415 created by the expression in the example code that begins ``(lambda
1419 (define my-account (make-account))
1426 This procedure acts as an account object with methods
1427 @code{get-balance}, @code{deposit} and @code{withdraw}. To apply one of
1428 the methods to the account, you call the procedure with a symbol
1429 indicating the required method as the first parameter, followed by any
1430 other parameters that are required by that method.
1433 (my-account 'get-balance)
1437 (my-account 'withdraw 5)
1441 (my-account 'deposit 396)
1445 (my-account 'get-balance)
1450 Note how, in this example, both the current balance and the helper
1451 procedures @code{get-balance}, @code{deposit} and @code{withdraw}, used
1452 to implement the guts of the account object's methods, are all stored in
1453 variable bindings within the private local environment captured by the
1454 @code{lambda} expression that creates the account object procedure.
1458 @c TeX-master: "guile.texi"