Sometimes you'll make mistakes when interacting with Scheme. This is quite normal, and if you've done it already, don't worry. When Scheme detects that something's wrong, it will complain. In most text-based Scheme systems, it will give you a special kind of prompt, so that you can type in commands to fix the mistake. In other systems, it may invoke a debugger, which is a program for diagnosing and fixing mistakes. For now, you need to know the command for your system that tells Scheme to give up on trying to fix the mistake, and go back to its normal "top level" interaction mode. Later, you should learn how to use the debugging facilities of your system, but for now just being able to get back to the normal Scheme prompt will do.
Assuming you've looked up the command for aborting an expression (by reading the manual, or asking a help system), you should try it out. You should make a mistake intentionally, watch what the system does, and make sure you can recover from your mistakes.
Here's a good mistake, and a hypothetical response from the Scheme, and a recovery to the normal Scheme prompt. Try this on your system, and make sure you can do the equivalent things:
Scheme>(2 3 4) ERROR: attempt to apply non-procedure 2 break[1]>,toplevel Scheme>
Here, we typed in the expression (2 3 4)
, which is illegal. The
Scheme system recognized it as a compound expression that's not a
special form, so it attempted to interpret it as a procedure call,
and apply the result of the first subexpression to the results of
the other subexpressions. In this case, the first subexpression is
2
, which evaluates to 2
, which isn't a procedure at
all. At that point, Scheme complained, telling us we'd tried to use
2
as a procedure, and switched to a "break loop" for debugging.
The break loop presented the special debugging prompt
break[1]>
, asking what to do about it. We typed in the special
command ,toplevel
to tell it to go back to normal interaction,
and it did, presenting us with a fresh Scheme>
prompt.
In your system, the prompts and commands are likely to be different. (For example, special commands may start with a colon, rather than a comma, and have different names.) Whatever they are, they'll be simple, and you should learn to use them as soon as possible. See the documentation for your system.
Here's another common mistake, which you will make pretty soon, so you should try it and see what happens and how to get out of it:
Scheme>a-variable ERROR: unbound variable: a-variable break[1]>,toplevel Scheme>
Here what happened is that we asked Scheme to evaluate the expression
a-variable
. Since a-variable
is just a normal identifier,
like a variable name, Scheme assumed it was supposed to be a variable
name, and that we were asking for its value. There wasn't a variable
named a-variable
, though, so Scheme complained. In Scheme
terminology for giving a piece of memory a name, we hadn't
defined that variable and "bound" it to storage. Scheme couldn't
find any storage by that name, much less fetch its value.
(Your system may let you get away with using set!
on an undefined
variable, silently creating a binding automatically. This is not
required by the Scheme standard, and programs generally should not
do this.)
As before, we used the special escape command to abort the attempt to evaluate this broken expression, and get back to normal interaction with Scheme.