(Debugging): New intro text. New subsection
[bpt/guile.git] / doc / ref / scheme-using.texi
CommitLineData
46f7666d
NJ
1@c -*-texinfo-*-
2@c This is part of the GNU Guile Reference Manual.
3@c Copyright (C) 2006
4@c Free Software Foundation, Inc.
5@c See the file guile.texi for copying conditions.
6
7@node Using Guile Interactively
8@section Using Guile Interactively
9
10When you start up Guile by typing just @code{guile}, without a
11@code{-c} argument or the name of a script to execute, you get an
12interactive interpreter where you can enter Scheme expressions, and
13Guile will evaluate them and print the results for you. Here are some
14simple examples.
15
16@lisp
17guile> (+ 3 4 5)
1812
19guile> (display "Hello world!\n")
20Hello world!
21guile> (values 'a 'b)
22a
23b
24@end lisp
25
26@noindent
27This mode of use is called a @dfn{REPL}, which is short for
28``Read-Eval-Print Loop'', because the Guile interpreter first reads the
29expression that you have typed, then evaluates it, and then prints the
30result.
31
32@menu
33* Readline::
34* Value Historyx::
35* Error Handling::
36* Interactive Debugger:: Using the interactive debugger.
37@end menu
38
39
40@node Readline
41@subsection Readline
42
43To make it easier for you to repeat and vary previously entered
44expressions, or to edit the expression that you're typing in, Guile
45can use the GNU Readline library. This is not enabled by default
46because of licensing reasons, but all you need to activate Readline is
47the following pair of lines.
48
49@lisp
50guile> (use-modules (ice-9 readline))
51guile> (activate-readline)
52@end lisp
53
54It's a good idea to put these two lines (without the ``guile>''
55prompts) in your @file{.guile} file. Guile reads this file when it
56starts up interactively, so anything in this file has the same effect
57as if you type it in by hand at the ``guile>'' prompt.
58
59
60@node Value Historyx
61@subsection Value History
62
63Just as Readline helps you to reuse a previous input line, @dfn{value
64history} allows you to use the @emph{result} of a previous evaluation
65in a new expression. When value history is enabled, each evaluation
66result is automatically assigned to the next in the sequence of
67variables @code{$1}, @code{$2}, @dots{}, and you can then use these
68variables in subsequent expressions.
69
70@lisp
71guile> (iota 10)
72$1 = (0 1 2 3 4 5 6 7 8 9)
73guile> (apply * (cdr $1))
74$2 = 362880
75guile> (sqrt $2)
76$3 = 602.3952191045344
77guile> (cons $2 $1)
78$4 = (362880 0 1 2 3 4 5 6 7 8 9)
79@end lisp
80
81To enable value history, type @code{(use-modules (ice-9 history))} at
82the Guile prompt, or add this to your @file{.guile} file. (It is not
83enabled by default, to avoid the possibility of conflicting with some
84other use you may have for the variables @code{$1}, @code{$2},
85@dots{}, and also because it prevents the stored evaluation results
86from being garbage collected, which some people may not want.)
87
88
89@node Error Handling
90@subsection Error Handling
91
92When code being evaluated from the REPL hits an error, Guile remembers
93the execution context where the error occurred and can give you three
94levels of information about what the error was and exactly where it
95occurred.
96
97By default, Guile then displays only the first level, which is the most
98immediate information about where and why the error occurred, for
99example:
100
101@lisp
102(make-string (* 4 (+ 3 #\s)) #\space)
103@print{}
104standard input:2:19: In procedure + in expression (+ 3 #\s):
105standard input:2:19: Wrong type argument: #\s
106ABORT: (wrong-type-arg)
107
108Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
109@end lisp
110
111@noindent
112However, as the message above says, you can obtain more information
113about the context of the error by typing @code{(backtrace)} or
114@code{(debug)}.
115
116@code{(backtrace)} displays the Scheme call stack at the point where the
117error occurred:
118
119@lisp
120(backtrace)
121@print{}
122Backtrace:
123In standard input:
124 2: 0* [make-string ...
125 2: 1* [* 4 ...
126 2: 2* [+ 3 #\s]
127
128Type "(debug-enable 'backtrace)" if you would like a backtrace
129automatically if an error occurs in the future.
130@end lisp
131
132@noindent
133In a more complex scenario than this one, this can be extremely useful
134for understanding where and why the error occurred. You can make Guile
135show the backtrace automatically by adding @code{(debug-enable
136'backtrace)} to your @file{.guile}.
137
138@code{(debug)} takes you into Guile's interactive debugger, which
139provides commands that allow you to
140
141@itemize @bullet
142@item
143display the Scheme call stack at the point where the error occurred
144(the @code{backtrace} command --- see @ref{Display Backtrace})
145
146@item
147move up and down the call stack, to see in detail the expression being
148evaluated, or the procedure being applied, in each @dfn{frame} (the
149@code{up}, @code{down}, @code{frame}, @code{position}, @code{info args}
150and @code{info frame} commands --- see @ref{Frame Selection} and
151@ref{Frame Information})
152
153@item
154examine the values of variables and expressions in the context of each
155frame (the @code{evaluate} command --- see @ref{Frame Evaluation}).
156@end itemize
157
158@noindent
159This is documented further in the following section.
160
161
162@node Interactive Debugger
163@subsection Using the Interactive Debugger
164
165Guile's interactive debugger is a command line application that accepts
166commands from you for examining the stack and, if at a breakpoint, for
167continuing program execution in various ways. Unlike in the normal
168Guile REPL, commands are typed mostly without parentheses.
169
170When you first enter the debugger, it introduces itself with a message
171like this:
172
173@lisp
174This is the Guile debugger -- for help, type `help'.
175There are 3 frames on the stack.
176
177Frame 2 at standard input:36:19
178 [+ 3 #\s]
179debug>
180@end lisp
181
182@noindent
183``debug>'' is the debugger's prompt, and a reminder that you are not in
184the normal Guile REPL. The available commands are described in the
185following subsections.
186
187@menu
188* Display Backtrace:: backtrace.
189* Frame Selection:: up, down, frame.
190* Frame Information:: info args, info frame, position.
191* Frame Evaluation:: evaluate.
192* Single Stepping:: step, next.
193* Run To Frame Exit:: finish, trace-finish.
194* Continue Execution:: continue.
195* Leave Debugger:: quit.
196@end menu
197
198
199@node Display Backtrace
200@subsubsection Display Backtrace
201
202The @code{backtrace} command, which can also be invoked as @code{bt} or
203@code{where}, displays the call stack (aka backtrace) at the point where
204the debugger was entered:
205
206@lisp
207debug> bt
208In standard input:
209 36: 0* [make-string ...
210 36: 1* [* 4 ...
211 36: 2* [+ 3 #\s]
212@end lisp
213
214@deffn {Debugger Command} backtrace [count]
215@deffnx {Debugger Command} bt [count]
216@deffnx {Debugger Command} where [count]
217Print backtrace of all stack frames, or of the innermost @var{count}
218frames. With a negative argument, print the outermost -@var{count}
219frames. If the number of frames isn't explicitly given, the debug
220option @code{depth} determines the maximum number of frames printed.
221@end deffn
222
223The format of the displayed backtrace is the same as for the
224@code{backtrace} procedure.
225
226
227@node Frame Selection
228@subsubsection Frame Selection
229
230A call stack consists of a sequence of stack @dfn{frames}, with each
231frame describing one level of the nested evaluations and applications
232that the program was executing when it hit a breakpoint or an error.
233Frames are numbered such that frame 0 is the outermost --- i.e. the
234operation on the call stack that began least recently --- and frame N-1
235the innermost (where N is the total number of frames on the stack).
236
237When you enter the debugger, the innermost frame is selected, which
238means that the commands for getting information about the ``current''
239frame, or for evaluating expressions in the context of the current
240frame, will do so by default with respect to the innermost frame. To
241select a different frame, so that these operations will apply to it
242instead, use the @code{up}, @code{down} and @code{frame} commands like
243this:
244
245@lisp
246debug> up
247Frame 1 at standard input:36:14
248 [* 4 ...
249debug> frame 0
250Frame 0 at standard input:36:1
251 [make-string ...
252debug> down
253Frame 1 at standard input:36:14
254 [* 4 ...
255@end lisp
256
257@deffn {Debugger Command} up [n]
258Move @var{n} frames up the stack. For positive @var{n}, this
259advances toward the outermost frame, to higher frame numbers, to
260frames that have existed longer. @var{n} defaults to one.
261@end deffn
262
263@deffn {Debugger Command} down [n]
264Move @var{n} frames down the stack. For positive @var{n}, this
265advances toward the innermost frame, to lower frame numbers, to frames
266that were created more recently. @var{n} defaults to one.
267@end deffn
268
269@deffn {Debugger Command} frame [n]
270Select and print a stack frame. With no argument, print the selected
271stack frame. (See also ``info frame''.) An argument specifies the
272frame to select; it must be a stack-frame number.
273@end deffn
274
275
276@node Frame Information
277@subsubsection Frame Information
278
279[to be completed]
280
281@deffn {Debugger Command} {info frame}
282All about selected stack frame.
283@end deffn
284
285@deffn {Debugger Command} {info args}
286Argument variables of current stack frame.
287@end deffn
288
289@deffn {Debugger Command} position
290Display the position of the current expression.
291@end deffn
292
293
294@node Frame Evaluation
295@subsubsection Frame Evaluation
296
297[to be completed]
298
299@deffn {Debugger Command} evaluate expression
300Evaluate an expression.
301The expression must appear on the same line as the command,
302however it may be continued over multiple lines.
303@end deffn
304
305
306@node Single Stepping
307@subsubsection Single Stepping
308
309[to be completed]
310
311@deffn {Debugger Command} step [n]
312Continue until entry to @var{n}th next frame.
313@end deffn
314
315@deffn {Debugger Command} next [n]
316Continue until entry to @var{n}th next frame in same file.
317@end deffn
318
319
320@node Run To Frame Exit
321@subsubsection Run To Frame Exit
322
323[to be completed]
324
325@deffn {Debugger Command} finish
326Continue until evaluation of the current frame is complete, and
327print the result obtained.
328@end deffn
329
330@deffn {Debugger Command} trace-finish
331Trace until evaluation of the current frame is complete.
332@end deffn
333
334
335@node Continue Execution
336@subsubsection Continue Execution
337
338[to be completed]
339
340@deffn {Debugger Command} continue
341Continue program execution.
342@end deffn
343
344
345@node Leave Debugger
346@subsubsection Leave Debugger
347
348[to be completed]
349
350@deffn {Debugger Command} quit
351Exit the debugger.
352@end deffn
353
354
355@node Using Guile in Emacs
356@section Using Guile in Emacs
357
358The Guile distribution includes a rich environment for working on Guile
359Scheme code within Emacs. The idea of this environment is to allow you
360to work on Guile Scheme code in the same kind of way that Emacs allows
361you to work on Emacs Lisp code: providing easy access to help,
362evaluating arbitrary fragments of code, a nice debugging interface, and
363so on.@footnote{You can also, of course, run a Guile session in Emacs
364simply by typing ``guile'' in a @code{*shell*} buffer. The environment
365described here provides a much better integration than that, though.}
366
367The thinking behind this environment is that you will usually be doing
368one of two things.
369
370@enumerate
371@item
372Writing or editing code. The code will be in a normal Emacs Scheme
373mode buffer, and the Guile/Emacs environment extends Scheme mode to
374add keystrokes and menu items for the things that are likely to be
375useful to you when working on code:
376
377@itemize
378@item
379completing the identifier at point
380@item
381accessing Guile's built in help
382@item
383evaluating fragments of code to check what they do.
384@end itemize
385
386@item
387Debugging a Guile Scheme program. When your program hits an error or
388a breakpoint, the Guile/Emacs environment shows you the relevant code
389and the Scheme stack, and makes it easy to
390
391@itemize
392@item
393look at the values of local variables
394@item
395see what is happening at all levels of the Scheme stack
396@item
397continue execution, either normally or step by step.
398@end itemize
399@end enumerate
400
401Combinations of these work well too. You can evaluate a fragment of
402code (in a Scheme buffer) that contains a breakpoint, then use the
403debugging interface to step through the code at the breakpoint. You
404can also run a program until it hits a breakpoint, then examine,
405modify and reevaluate some of the relevant code, and then tell the
406program to continue running.
407
408
409@c Local Variables:
410@c TeX-master: "guile.texi"
411@c End: