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>
 |