Commit | Line | Data |
---|---|---|
07d83abe MV |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Guile Reference Manual. | |
48eb9021 MW |
3 | @c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2009, 2010, 2011, |
4 | @c 2014 Free Software Foundation, Inc. | |
07d83abe MV |
5 | @c See the file guile.texi for copying conditions. |
6 | ||
07d83abe MV |
7 | @node Binding Constructs |
8 | @section Definitions and Variable Bindings | |
9 | ||
07d83abe MV |
10 | Scheme supports the definition of variables in different contexts. |
11 | Variables can be defined at the top level, so that they are visible in | |
12 | the entire program, and variables can be defined locally to procedures | |
13 | and expressions. This is important for modularity and data abstraction. | |
14 | ||
15 | @menu | |
16 | * Top Level:: Top level variable definitions. | |
17 | * Local Bindings:: Local variable bindings. | |
18 | * Internal Definitions:: Internal definitions. | |
19 | * Binding Reflection:: Querying variable bindings. | |
48eb9021 | 20 | * Binding Multiple Values:: Binding multiple return values. |
07d83abe MV |
21 | @end menu |
22 | ||
23 | ||
24 | @node Top Level | |
25 | @subsection Top Level Variable Definitions | |
26 | ||
27 | @cindex variable definition | |
28 | ||
935c7aca | 29 | At the top level of a program (i.e., not nested within any other |
07d83abe MV |
30 | expression), a definition of the form |
31 | ||
32 | @lisp | |
33 | (define a @var{value}) | |
34 | @end lisp | |
35 | ||
36 | @noindent | |
37 | defines a variable called @code{a} and sets it to the value @var{value}. | |
38 | ||
935c7aca AW |
39 | If the variable already exists in the current module, because it has |
40 | already been created by a previous @code{define} expression with the | |
41 | same name, its value is simply changed to the new @var{value}. In this | |
42 | case, then, the above form is completely equivalent to | |
07d83abe MV |
43 | |
44 | @lisp | |
45 | (set! a @var{value}) | |
46 | @end lisp | |
47 | ||
48 | @noindent | |
49 | This equivalence means that @code{define} can be used interchangeably | |
50 | with @code{set!} to change the value of variables at the top level of | |
51 | the REPL or a Scheme source file. It is useful during interactive | |
52 | development when reloading a Scheme file that you have modified, because | |
53 | it allows the @code{define} expressions in that file to work as expected | |
54 | both the first time that the file is loaded and on subsequent occasions. | |
55 | ||
56 | Note, though, that @code{define} and @code{set!} are not always | |
57 | equivalent. For example, a @code{set!} is not allowed if the named | |
58 | variable does not already exist, and the two expressions can behave | |
59 | differently in the case where there are imported variables visible from | |
60 | another module. | |
61 | ||
62 | @deffn {Scheme Syntax} define name value | |
63 | Create a top level variable named @var{name} with value @var{value}. | |
64 | If the named variable already exists, just change its value. The return | |
65 | value of a @code{define} expression is unspecified. | |
66 | @end deffn | |
67 | ||
68 | The C API equivalents of @code{define} are @code{scm_define} and | |
69 | @code{scm_c_define}, which differ from each other in whether the | |
70 | variable name is specified as a @code{SCM} symbol or as a | |
71 | null-terminated C string. | |
72 | ||
73 | @deffn {C Function} scm_define (sym, value) | |
74 | @deffnx {C Function} scm_c_define (const char *name, value) | |
75 | C equivalents of @code{define}, with variable name specified either by | |
76 | @var{sym}, a symbol, or by @var{name}, a null-terminated C string. Both | |
77 | variants return the new or preexisting variable object. | |
78 | @end deffn | |
79 | ||
80 | @code{define} (when it occurs at top level), @code{scm_define} and | |
81 | @code{scm_c_define} all create or set the value of a variable in the top | |
82 | level environment of the current module. If there was not already a | |
83 | variable with the specified name belonging to the current module, but a | |
84 | similarly named variable from another module was visible through having | |
85 | been imported, the newly created variable in the current module will | |
86 | shadow the imported variable, such that the imported variable is no | |
87 | longer visible. | |
88 | ||
89 | Attention: Scheme definitions inside local binding constructs | |
90 | (@pxref{Local Bindings}) act differently (@pxref{Internal Definitions}). | |
91 | ||
c5f30c4c AW |
92 | Many people end up in a development style of adding and changing |
93 | definitions at runtime, building out their program without restarting | |
94 | it. (You can do this using @code{reload-module}, the @code{reload} REPL | |
95 | command, the @code{load} procedure, or even just pasting code into a | |
96 | REPL.) If you are one of these people, you will find that sometimes you | |
97 | there are some variables that you @emph{don't} want to redefine all the | |
98 | time. For these, use @code{define-once}. | |
99 | ||
100 | @fnindex defvar | |
101 | @deffn {Scheme Syntax} define-once name value | |
102 | Create a top level variable named @var{name} with value @var{value}, but | |
103 | only if @var{name} is not already bound in the current module. | |
104 | @end deffn | |
105 | ||
106 | Old Lispers probably know @code{define-once} under its Lisp name, | |
107 | @code{defvar}. | |
108 | ||
07d83abe MV |
109 | |
110 | @node Local Bindings | |
111 | @subsection Local Variable Bindings | |
112 | ||
07d83abe MV |
113 | @cindex local bindings |
114 | @cindex local variables | |
115 | ||
935c7aca AW |
116 | As opposed to definitions at the top level, which creates bindings that |
117 | are visible to all code in a module, it is also possible to define | |
118 | variables which are only visible in a well-defined part of the program. | |
119 | Normally, this part of a program will be a procedure or a subexpression | |
120 | of a procedure. | |
07d83abe | 121 | |
935c7aca AW |
122 | With the constructs for local binding (@code{let}, @code{let*}, |
123 | @code{letrec}, and @code{letrec*}), the Scheme language has a block | |
124 | structure like most other programming languages since the days of | |
125 | @sc{Algol 60}. Readers familiar to languages like C or Java should | |
126 | already be used to this concept, but the family of @code{let} | |
127 | expressions has a few properties which are well worth knowing. | |
07d83abe | 128 | |
935c7aca | 129 | The most basic local binding construct is @code{let}. |
07d83abe MV |
130 | |
131 | @deffn syntax let bindings body | |
132 | @var{bindings} has the form | |
133 | ||
134 | @lisp | |
135 | ((@var{variable1} @var{init1}) @dots{}) | |
136 | @end lisp | |
137 | ||
138 | that is zero or more two-element lists of a variable and an arbitrary | |
139 | expression each. All @var{variable} names must be distinct. | |
140 | ||
141 | A @code{let} expression is evaluated as follows. | |
142 | ||
143 | @itemize @bullet | |
144 | @item | |
145 | All @var{init} expressions are evaluated. | |
146 | ||
147 | @item | |
148 | New storage is allocated for the @var{variables}. | |
149 | ||
150 | @item | |
151 | The values of the @var{init} expressions are stored into the variables. | |
152 | ||
153 | @item | |
154 | The expressions in @var{body} are evaluated in order, and the value of | |
155 | the last expression is returned as the value of the @code{let} | |
156 | expression. | |
07d83abe MV |
157 | @end itemize |
158 | ||
159 | The @var{init} expressions are not allowed to refer to any of the | |
160 | @var{variables}. | |
161 | @end deffn | |
162 | ||
ecb87335 | 163 | The other binding constructs are variations on the same theme: making new |
935c7aca AW |
164 | values, binding them to variables, and executing a body in that new, |
165 | extended lexical context. | |
166 | ||
07d83abe MV |
167 | @deffn syntax let* bindings body |
168 | Similar to @code{let}, but the variable bindings are performed | |
169 | sequentially, that means that all @var{init} expression are allowed to | |
170 | use the variables defined on their left in the binding list. | |
171 | ||
172 | A @code{let*} expression can always be expressed with nested @code{let} | |
173 | expressions. | |
174 | ||
175 | @lisp | |
176 | (let* ((a 1) (b a)) | |
177 | b) | |
178 | @equiv{} | |
179 | (let ((a 1)) | |
180 | (let ((b a)) | |
181 | b)) | |
182 | @end lisp | |
183 | @end deffn | |
184 | ||
185 | @deffn syntax letrec bindings body | |
186 | Similar to @code{let}, but it is possible to refer to the @var{variable} | |
187 | from lambda expression created in any of the @var{inits}. That is, | |
188 | procedures created in the @var{init} expression can recursively refer to | |
189 | the defined variables. | |
190 | ||
191 | @lisp | |
935c7aca AW |
192 | (letrec ((even? (lambda (n) |
193 | (if (zero? n) | |
194 | #t | |
195 | (odd? (- n 1))))) | |
196 | (odd? (lambda (n) | |
197 | (if (zero? n) | |
198 | #f | |
199 | (even? (- n 1)))))) | |
07d83abe MV |
200 | (even? 88)) |
201 | @result{} | |
202 | #t | |
203 | @end lisp | |
935c7aca AW |
204 | |
205 | Note that while the @var{init} expressions may refer to the new | |
206 | variables, they may not access their values. For example, making the | |
207 | @code{even?} function above creates a closure (@pxref{About Closure}) | |
208 | referencing the @code{odd?} variable. But @code{odd?} can't be called | |
209 | until after execution has entered the body. | |
210 | @end deffn | |
211 | ||
212 | @deffn syntax letrec* bindings body | |
213 | Similar to @code{letrec}, except the @var{init} expressions are bound to | |
214 | their variables in order. | |
215 | ||
216 | @code{letrec*} thus relaxes the letrec restriction, in that later | |
217 | @var{init} expressions may refer to the values of previously bound | |
218 | variables. | |
219 | ||
220 | @lisp | |
221 | (letrec ((a 42) | |
51607806 | 222 | (b (+ a 10))) ;; Illegal access |
935c7aca | 223 | (* a b)) |
51607806 | 224 | ;; The behavior of the expression above is unspecified |
935c7aca AW |
225 | |
226 | (letrec* ((a 42) | |
227 | (b (+ a 10))) | |
228 | (* a b)) | |
229 | @result{} 2184 | |
230 | @end lisp | |
07d83abe MV |
231 | @end deffn |
232 | ||
233 | There is also an alternative form of the @code{let} form, which is used | |
234 | for expressing iteration. Because of the use as a looping construct, | |
235 | this form (the @dfn{named let}) is documented in the section about | |
236 | iteration (@pxref{while do, Iteration}) | |
237 | ||
238 | @node Internal Definitions | |
239 | @subsection Internal definitions | |
240 | ||
241 | @c FIXME::martin: Review me! | |
242 | ||
243 | A @code{define} form which appears inside the body of a @code{lambda}, | |
935c7aca AW |
244 | @code{let}, @code{let*}, @code{letrec}, @code{letrec*} or equivalent |
245 | expression is called an @dfn{internal definition}. An internal | |
246 | definition differs from a top level definition (@pxref{Top Level}), | |
247 | because the definition is only visible inside the complete body of the | |
248 | enclosing form. Let us examine the following example. | |
07d83abe MV |
249 | |
250 | @lisp | |
251 | (let ((frumble "froz")) | |
252 | (define banana (lambda () (apple 'peach))) | |
253 | (define apple (lambda (x) x)) | |
254 | (banana)) | |
255 | @result{} | |
256 | peach | |
257 | @end lisp | |
258 | ||
259 | Here the enclosing form is a @code{let}, so the @code{define}s in the | |
260 | @code{let}-body are internal definitions. Because the scope of the | |
261 | internal definitions is the @strong{complete} body of the | |
935c7aca AW |
262 | @code{let}-expression, the @code{lambda}-expression which gets bound to |
263 | the variable @code{banana} may refer to the variable @code{apple}, even | |
264 | though its definition appears lexically @emph{after} the definition of | |
265 | @code{banana}. This is because a sequence of internal definition acts | |
266 | as if it were a @code{letrec*} expression. | |
07d83abe MV |
267 | |
268 | @lisp | |
269 | (let () | |
270 | (define a 1) | |
271 | (define b 2) | |
272 | (+ a b)) | |
273 | @end lisp | |
274 | ||
275 | @noindent | |
276 | is equivalent to | |
277 | ||
278 | @lisp | |
279 | (let () | |
935c7aca | 280 | (letrec* ((a 1) (b 2)) |
07d83abe MV |
281 | (+ a b))) |
282 | @end lisp | |
283 | ||
935c7aca AW |
284 | Internal definitions are only allowed at the beginning of the body of an |
285 | enclosing expression. They may not be mixed with other expressions. | |
286 | ||
07d83abe MV |
287 | Another noteworthy difference to top level definitions is that within |
288 | one group of internal definitions all variable names must be distinct. | |
289 | That means where on the top level a second define for a given variable | |
290 | acts like a @code{set!}, an exception is thrown for internal definitions | |
291 | with duplicate bindings. | |
292 | ||
935c7aca AW |
293 | As a historical note, it used to be that internal bindings were expanded |
294 | in terms of @code{letrec}, not @code{letrec*}. This was the situation | |
295 | for the R5RS report and before. However with the R6RS, it was recognized | |
296 | that sequential definition was a more intuitive expansion, as in the | |
297 | following case: | |
07d83abe | 298 | |
935c7aca AW |
299 | @lisp |
300 | (let () | |
301 | (define a 1) | |
302 | (define b (+ a a)) | |
303 | (+ a b)) | |
304 | @end lisp | |
305 | ||
306 | @noindent | |
307 | Guile decided to follow the R6RS in this regard, and now expands | |
308 | internal definitions using @code{letrec*}. | |
07d83abe | 309 | |
07d83abe MV |
310 | |
311 | @node Binding Reflection | |
312 | @subsection Querying variable bindings | |
313 | ||
314 | Guile provides a procedure for checking whether a symbol is bound in the | |
315 | top level environment. | |
316 | ||
dab1ed37 LC |
317 | @deffn {Scheme Procedure} defined? sym [module] |
318 | @deffnx {C Function} scm_defined_p (sym, module) | |
319 | Return @code{#t} if @var{sym} is defined in the module @var{module} or | |
320 | the current module when @var{module} is not specified; otherwise return | |
321 | @code{#f}. | |
07d83abe MV |
322 | @end deffn |
323 | ||
324 | ||
48eb9021 MW |
325 | @node Binding Multiple Values |
326 | @subsection Binding multiple return values | |
327 | ||
328 | @deffn {Syntax} define-values formals expression | |
329 | The @var{expression} is evaluated, and the @var{formals} are bound to | |
330 | the return values in the same way that the formals in a @code{lambda} | |
331 | expression are matched to the arguments in a procedure call. | |
332 | @end deffn | |
333 | ||
334 | @example | |
335 | (define-values (q r) (floor/ 10 3)) | |
336 | (list q r) @result{} (3 1) | |
337 | ||
338 | (define-values (x . y) (values 1 2 3)) | |
339 | x @result{} 1 | |
340 | y @result{} (2 3) | |
341 | ||
342 | (define-values x (values 1 2 3)) | |
343 | x @result{} (1 2 3) | |
344 | @end example | |
345 | ||
346 | ||
07d83abe MV |
347 | @c Local Variables: |
348 | @c TeX-master: "guile.texi" | |
349 | @c End: |