Scheme is a small standard specification for a family of programming languages. PLT Scheme is a useful implementation of Scheme. It comes with a graphical programming environment, DrScheme, that helps beginners and experienced programmers alike. With DrScheme, you can calculate, explore Scheme, write script, and program serious applications.
While we assume that you have heard of Scheme before  otherwise you wouldn't be here  we know that you may be a bit rusty or that you may just have a first impression, though you have programmed in some other language before. If that's the case, this chapter is for you. It starts out with a quick tutorial on DrScheme and then presents the very core of the Scheme language in the spirit of ``How to Design Programs.'' As you work your way through these sections on Scheme, use DrScheme to get reacquainted with our favorite programming language.
When you start DrScheme for the first time, you see two distinct panels. The top panel is called the DEFINITIONS WINDOW, the bottom panel is the INTERACTIONS WINDOW. With the toplevel window, you program; with the toplevel window, you usually compute. Let's take a closer look at these two windows and the role they play.
The Interactions window is the core of DrScheme, and roughly speaking, this is just a fancy calculator. It ``listens'' to you. After you type in a (complete) Scheme expression, it reads it, evaluates it, and prints the result. Let's see how this works.
Initially, the Interactions window is the lower half of DrScheme:

DrScheme's prompts users with > to enter an expression. Once we have typed a completely parenthesized expression and hit return, it prints the result on the next line. Although the example here isn't particularly interesting, it is comforting to know that Scheme computes such simple things well and correctly.
Use Pretty Big Scheme for this section. 
Here are some more interactions:

DrScheme also knows other functions that we might find on a calculator:

1
.
Take a look at this sequence of interactions now:

price
and quantity
. They represent 9.95
and 225
,
respectively. The third definition specifies that cost
is to
stand for the product of price
and quantity
. By entering
cost
right afterwards, we see that is indeed 2238.75
,
which is the same as multiplying 9.95
and 225
, as the
next interaction shows. The last three interactions compute the
tax
for this imaginary sale and the total
cost. To do
so, we use the variable cost
twice.
If we need to calculate the taxed total of some sale many times, we may
wish to ``teach'' the calculator a new trick, or as we say, a new
function. Even if we don't know what the raw cost is, we can use a name,
say rawcost
, to represent the cost and act as if it were a
number. Then the cost with tax is (+ rawcost (* .05 rawcost))
.
This relationship between a variable, which represents some
unknown number, and some expression is a function. If we give the
relationship a name, we can use it as many times as we wish.

This function definition says that the name of the function is
costplustax
, that it expects one argument, like say
sqrt
, and how the result is computed in terms of this yet unknown
argument value. The next three interactions explain how to use a function
that we defined. Not surprisingly, this is just like using a function that
DrScheme provides. The first use of costplustax
validates that
the function computes the same result as the calculation above. And now we
can use this function over and over again.
Clearly, variable definitions and function definitions are worksaving devices, the first step toward programming. Defining functions and variables in the Interactions window, however, is not good if we wish to keep these definitions around for a long time or if we wish to develop a large number of interacting functions. To this end, it is better to use the definitions window.
Let's continue with our example. Instead of entering the function
definition of costplustax
into the Interactions window, we type
it into the definitions window and save it in a file:

While computing the cost plus the tax of a total sale saves some work, we
should of course define a function that consumes the price
and the
quantity
of our imaginary sales item and that produces the total
cost, including tax. Since we know that the cost is
(* price quantity)
,
the tax is therefore^{1}
(* .05 price quantity)
Adding these two quantities produces the total of a sale relative to the
variables price
and quantity
.
Using this reasoning, we can define the function totalcost
:

costplustax
above except that this new
function also performs the necessary multiplications for us.
Take a moment to compare the definition of totalcost
and the
interactions that we used when we first determined the total cost of 225
items that cost $9.95. Back then, we used the variables cost
and
tax
to remember intermediate results of the calculation. By doing
so, we broke down the calculations in smaller, possibly more comprehsible
pieces. Naturally, we can do the same thing when we define functions.
Here is a revision of totalcost
:

local
with which we can turn a sequence of
definitions from the Interactions window into local definitions in a
function body. The screen dump also shows how DrScheme's syntax
highlighting works in a lexically sensitive manner. By mousing over
variables a programmer asks for arrows that show where a variable is bound
and from where its value originates. With another right click on the
mouse, the programmer can also systematically rename variables without
interfering with the lexical structure of the program.
^{1} Yes, once we accept prefix syntax, where the operator is mentioned first and the operands afterwards, we get some advantages over the whimsical mathematical syntax that schools try to teach us over 12 years.