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 top-level window, you program; with the top-level 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:
Take a look at this sequence of interactions now:
quantity. They represent
225, respectively. The third definition specifies that
costis to stand for the product of
quantity. By entering
costright afterwards, we see that is indeed
2238.75, which is the same as multiplying
225, as the next interaction shows. The last three interactions compute the
taxfor this imaginary sale and the
totalcost. To do so, we use the variable
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,
raw-cost, to represent the cost and act as if it were a
number. Then the cost with tax is
(+ raw-cost (* .05 raw-cost)).
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
cost-plus-tax, 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
cost-plus-tax 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 work-saving 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
cost-plus-tax 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 therefore1
(* .05 price quantity)
Adding these two quantities produces the total of a sale relative to the
Using this reasoning, we can define the function
cost-plus-taxabove except that this new function also performs the necessary multiplications for us.
Take a moment to compare the definition of
total-cost 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
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
localwith 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 high-lighting 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.