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