199 lines
9.4 KiB
HTML
199 lines
9.4 KiB
HTML
|
<!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- Generated from TeX source by tex2page, v 4o4,
|
||
|
|
(c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
|
||
|
|
<head>
|
||
|
|
<title>
|
||
|
|
Revised^5 Report on the Algorithmic Language Scheme
|
||
|
|
</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="r5rs-Z-C.css" title=default>
|
||
|
|
<meta name=robots content="noindex,follow">
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<p><div class=navigation>[Go to <span><a href="r5rs.html">first</a>, <a href="r5rs-Z-H-7.html">previous</a></span><span>, <a href="r5rs-Z-H-9.html">next</a></span> page<span>; </span><span><a href="r5rs-Z-H-2.html#%_toc_start">contents</a></span><span><span>; </span><a href="r5rs-Z-H-15.html#%_index_start">index</a></span>]</div><p>
|
||
|
|
|
||
|
|
<a name="%_chap_5"></a>
|
||
|
|
<h1 class=chapter>
|
||
|
|
<div class=chapterheading><a href="r5rs-Z-H-2.html#%_toc_%_chap_5">Chapter 5</a></div><p>
|
||
|
|
<a href="r5rs-Z-H-2.html#%_toc_%_chap_5">Program structure</a></h1><p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="%_sec_5.1"></a>
|
||
|
|
<h2><a href="r5rs-Z-H-2.html#%_toc_%_sec_5.1">5.1 Programs</a></h2><p>
|
||
|
|
|
||
|
|
A Scheme program consists of a sequence of expressions, definitions,
|
||
|
|
and syntax definitions.
|
||
|
|
Expressions are described in chapter <a href="r5rs-Z-H-7.html#%_chap_4">4</a>;
|
||
|
|
definitions and syntax definitions are the subject of the rest of the
|
||
|
|
present chapter.<p>
|
||
|
|
|
||
|
|
Programs are typically stored in files or entered interactively to a
|
||
|
|
running Scheme system, although other paradigms are possible;
|
||
|
|
questions of user interface lie outside the scope of this report.
|
||
|
|
(Indeed, Scheme would still be useful as a notation for expressing
|
||
|
|
computational methods even in the absence of a mechanical
|
||
|
|
implementation.)<p>
|
||
|
|
|
||
|
|
Definitions and syntax definitions occurring at the top level of a program
|
||
|
|
can be interpreted
|
||
|
|
declaratively.
|
||
|
|
They cause bindings to be created in the top level
|
||
|
|
environment or modify the value of existing top-level bindings.
|
||
|
|
Expressions occurring at the top level of a program are
|
||
|
|
interpreted imperatively; they are executed in order when the program is
|
||
|
|
invoked or loaded, and typically perform some kind of initialization.<p>
|
||
|
|
|
||
|
|
At the top level of a program <tt>(begin <form<sub>1</sub>> <tt>...</tt>)</tt> is
|
||
|
|
equivalent to the sequence of expressions, definitions, and syntax definitions
|
||
|
|
that form the body of the <tt>begin</tt>.<p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="%_sec_5.2"></a>
|
||
|
|
<h2><a href="r5rs-Z-H-2.html#%_toc_%_sec_5.2">5.2 Definitions</a></h2><p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
Definitions are valid in some, but not all, contexts where expressions
|
||
|
|
are allowed. They are valid only at the top level of a <program>
|
||
|
|
and at the beginning of a <body>.
|
||
|
|
<a name="%_idx_188"></a><p>
|
||
|
|
|
||
|
|
A definition should have one of the following forms:<a name="%_idx_190"></a><p>
|
||
|
|
|
||
|
|
<p><ul><p>
|
||
|
|
|
||
|
|
<li><tt>(define <variable> <expression>)</tt><p>
|
||
|
|
|
||
|
|
<li><tt>(define (<variable> <formals>) <body>)</tt><p>
|
||
|
|
|
||
|
|
<Formals> should be either a
|
||
|
|
sequence of zero or more variables, or a sequence of one or more
|
||
|
|
variables followed by a space-delimited period and another variable (as
|
||
|
|
in a lambda expression). This form is equivalent to
|
||
|
|
<tt><p>(define <variable><br>
|
||
|
|
(lambda (<formals>) <body>)).<p></tt><p>
|
||
|
|
|
||
|
|
<li><tt>(define (<variable> . <formal>) <body>)</tt><p>
|
||
|
|
|
||
|
|
<Formal> should be a single
|
||
|
|
variable. This form is equivalent to
|
||
|
|
<tt><p>(define <variable><br>
|
||
|
|
(lambda <formal> <body>)).<p></tt><p>
|
||
|
|
|
||
|
|
</ul><p><p>
|
||
|
|
|
||
|
|
<a name="%_sec_5.2.1"></a>
|
||
|
|
<h3><a href="r5rs-Z-H-2.html#%_toc_%_sec_5.2.1">5.2.1 Top level definitions</a></h3><p>
|
||
|
|
|
||
|
|
At the top level of a program, a definition
|
||
|
|
<tt><p>(define <variable> <expression>)<p></tt>
|
||
|
|
has essentially the same effect as the assignment expression
|
||
|
|
<tt><p>(<tt>set!</tt> <variable> <expression>)<p></tt>
|
||
|
|
if <variable> is bound. If <variable> is not bound,
|
||
|
|
however, then the definition will bind <variable> to a new
|
||
|
|
location before performing the assignment, whereas it would be an error
|
||
|
|
to perform a <tt>set!</tt> on an unbound<a name="%_idx_192"></a> variable.<p>
|
||
|
|
|
||
|
|
<tt><p>(define add3<br>
|
||
|
|
(lambda (x) (+ x 3)))<br>
|
||
|
|
(add3 3) ===> 6<br>
|
||
|
|
(define first car)<br>
|
||
|
|
(first '(1 2)) ===> 1<p></tt><p>
|
||
|
|
|
||
|
|
Some implementations of Scheme use an initial environment in
|
||
|
|
which all possible variables are bound to locations, most of
|
||
|
|
which contain undefined values. Top level definitions in
|
||
|
|
such an implementation are truly equivalent to assignments.<p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="%_sec_5.2.2"></a>
|
||
|
|
<h3><a href="r5rs-Z-H-2.html#%_toc_%_sec_5.2.2">5.2.2 Internal definitions</a></h3><p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
Definitions may occur at the
|
||
|
|
beginning of a <body> (that is, the body of a <tt>lambda</tt>,
|
||
|
|
<tt>let</tt>, <tt>let*</tt>, <tt>letrec</tt>, <tt>let-syntax</tt>, or <tt>letrec-syntax</tt>
|
||
|
|
expression or that of a definition of an appropriate form).
|
||
|
|
Such definitions are known as <em>internal definitions</em> <a name="%_idx_194"></a> as opposed to the top level definitions described above.
|
||
|
|
The variable defined by an internal definition is local to the
|
||
|
|
<body>. That is, <variable> is bound rather than assigned,
|
||
|
|
and the region of the binding is the entire <body>. For example,<p>
|
||
|
|
|
||
|
|
<tt><p>(let ((x 5))<br>
|
||
|
|
(define foo (lambda (y) (bar x y)))<br>
|
||
|
|
(define bar (lambda (a b) (+ (* a b) a)))<br>
|
||
|
|
(foo (+ x 3))) ===> 45<p></tt><p>
|
||
|
|
|
||
|
|
A <body> containing internal definitions can always be converted
|
||
|
|
into a completely equivalent <tt>letrec</tt> expression. For example, the
|
||
|
|
<tt>let</tt> expression in the above example is equivalent to<p>
|
||
|
|
|
||
|
|
<tt><p>(let ((x 5))<br>
|
||
|
|
(letrec ((foo (lambda (y) (bar x y)))<br>
|
||
|
|
(bar (lambda (a b) (+ (* a b) a))))<br>
|
||
|
|
(foo (+ x 3))))<p></tt><p>
|
||
|
|
|
||
|
|
Just as for the equivalent <tt>letrec</tt> expression, it must be
|
||
|
|
possible to evaluate each <expression> of every internal
|
||
|
|
definition in a <body> without assigning or referring to
|
||
|
|
the value of any <variable> being defined.<p>
|
||
|
|
|
||
|
|
Wherever an internal definition may occur
|
||
|
|
<tt>(begin <definition<sub>1</sub>> <tt>...</tt>)</tt>
|
||
|
|
is equivalent to the sequence of definitions
|
||
|
|
that form the body of the <tt>begin</tt>.<p>
|
||
|
|
|
||
|
|
<a name="%_sec_5.3"></a>
|
||
|
|
<h2><a href="r5rs-Z-H-2.html#%_toc_%_sec_5.3">5.3 Syntax definitions</a></h2><p>
|
||
|
|
|
||
|
|
Syntax definitions are valid only at the top level of a <program>.
|
||
|
|
<a name="%_idx_196"></a>
|
||
|
|
They have the following form:<a name="%_idx_198"></a><p>
|
||
|
|
|
||
|
|
<tt>(define-syntax <keyword> <transformer spec>)</tt><p>
|
||
|
|
|
||
|
|
<Keyword> is an identifier, and
|
||
|
|
the <transformer spec> should be an instance of <tt>syntax-rules</tt>.
|
||
|
|
The top-level syntactic environment is extended by binding the
|
||
|
|
<keyword> to the specified transformer.<p>
|
||
|
|
|
||
|
|
There is no <tt>define-syntax</tt> analogue of internal definitions.<p>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
Although macros may expand into definitions and syntax definitions in
|
||
|
|
any context that permits them, it is an error for a definition or syntax
|
||
|
|
definition to shadow a syntactic keyword whose meaning is needed to
|
||
|
|
determine whether some form in the group of forms that contains the
|
||
|
|
shadowing definition is in fact a definition, or, for internal definitions,
|
||
|
|
is needed to determine the boundary between the group and the expressions
|
||
|
|
that follow the group. For example, the following are errors:<p>
|
||
|
|
|
||
|
|
<tt><p>(define define 3)<br>
|
||
|
|
<br>
|
||
|
|
(begin (define begin list))<br>
|
||
|
|
<br>
|
||
|
|
(let-syntax<br>
|
||
|
|
((foo (syntax-rules ()<br>
|
||
|
|
((foo (proc args ...) body ...)<br>
|
||
|
|
(define proc<br>
|
||
|
|
(lambda (args ...)<br>
|
||
|
|
body ...))))))<br>
|
||
|
|
(let ((x 3))<br>
|
||
|
|
(foo (plus x y) (+ x y))<br>
|
||
|
|
(define foo x)<br>
|
||
|
|
(plus foo x)))<br>
|
||
|
|
<p></tt><p>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<p><div class=navigation>[Go to <span><a href="r5rs.html">first</a>, <a href="r5rs-Z-H-7.html">previous</a></span><span>, <a href="r5rs-Z-H-9.html">next</a></span> page<span>; </span><span><a href="r5rs-Z-H-2.html#%_toc_start">contents</a></span><span><span>; </span><a href="r5rs-Z-H-15.html#%_index_start">index</a></span>]</div><p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|