Commit | Line | Data |
---|---|---|
a0e07ba4 NJ |
1 | \input texinfo @c -*-texinfo-*- |
2 | @c %**start of header | |
3 | @setfilename r5rs.info | |
4 | @settitle Revised(5) Scheme | |
5 | ||
6 | @c This copy of r5rs.texi differs from Aubrey Jaffer's master copy | |
7 | @c by a set of changes to allow the building of r5rs.dvi from r5rs.texi. | |
8 | @c Aubrey Jaffer's view - which I agree with - is that, given that | |
9 | @c people have the option of building r5rs.dvi from the original | |
10 | @c LaTeX distribution for R5RS, it is not worth fixing his master | |
11 | @c copy of r5rs.texi and the tool which autogenerates it. On the | |
12 | @c other hand, it is a marginal convenience for people to be able to | |
13 | @c build hardcopy from r5rs.texi, even if the results are less good | |
14 | @c than with the original LaTeX. Hence the following fixes. | |
15 | @c (lines 714, 725, 728, 1614, 2258): Remove invalid parentheses from | |
16 | @c @deffn statements. | |
17 | @c (line 2316): Change @deffnx to @deffn, and insert `@end deffn' to | |
18 | @c terminate preceding @deffn. | |
19 | @c (line 7320): Insert `@c ' at beginning of lines that are intended | |
20 | @c to be @ignore'd. | |
21 | @c | |
22 | @c NJ 2001/1/26 | |
23 | ||
24 | @c \documentclass[twoside]{algol60} | |
25 | ||
26 | @c \pagestyle{headings} | |
27 | @c \showboxdepth=0 | |
28 | ||
29 | ||
30 | ||
31 | @c \def\headertitle{Revised$^{5}$ Scheme} | |
32 | @c \def\integerversion{5} | |
33 | ||
34 | @c Sizes and dimensions | |
35 | ||
36 | @c \topmargin -.375in % Nominal distance from top of page to top of | |
37 | ||
38 | @c box containing running head. | |
39 | @c \headsep 15pt % Space between running head and text. | |
40 | ||
41 | @c \textheight 663pt % Height of text (including footnotes and figures, | |
42 | ||
43 | @c excluding running head and foot). | |
44 | ||
45 | @c \textwidth 523pt % Width of text line. | |
46 | @c \columnsep 15pt % Space between columns | |
47 | @c \columnseprule 0pt % Width of rule between columns. | |
48 | ||
49 | @c \parskip 5pt plus 2pt minus 2pt % Extra vertical space between paragraphs. | |
50 | @c \parindent 0pt % Width of paragraph indentation. | |
51 | @c \topsep 0pt plus 2pt % Extra vertical space, in addition to | |
52 | ||
53 | @c \parskip, added above and below list and | |
54 | ||
55 | @c paragraphing environments. | |
56 | ||
57 | @c \oddsidemargin -.5in % Left margin on odd-numbered pages. | |
58 | @c \evensidemargin -.5in % Left margin on even-numbered pages. | |
59 | ||
60 | @c % End of sizes and dimensions | |
61 | ||
62 | @paragraphindent 0 | |
63 | @c %**end of header | |
64 | @c syncodeindex fn cp | |
65 | ||
66 | @ifinfo | |
67 | @dircategory The Algorithmic Language Scheme | |
68 | @direntry | |
69 | * R5RS: (r5rs). The Revised(5) Report on Scheme. | |
70 | @end direntry | |
71 | @end ifinfo | |
72 | ||
73 | ||
74 | @c \parindent 0pt %!! 15pt % Width of paragraph indentation. | |
75 | ||
76 | @b{20 February 1998} | |
77 | @c \hfil \today{} | |
78 | ||
79 | @c @include{first} | |
80 | @titlepage | |
81 | ||
82 | @c HTML first page | |
83 | @title Scheme | |
84 | @subtitle Revised(5) Report on the Algorithmic Language Scheme | |
85 | @c First page | |
86 | ||
87 | @c \thispagestyle{empty} | |
88 | ||
89 | @c \todo{"another" report?} | |
90 | ||
91 | ||
92 | @author R@sc{ICHARD} K@sc{ELSEY}, W@sc{ILLIAM} C@sc{LINGER, AND} J@sc{ONATHAN} R@sc{EES} (@i{Editors}) | |
93 | @author H. A@sc{BELSON} | |
94 | @author R. K. D@sc{YBVIG} | |
95 | @author C. T. H@sc{AYNES} | |
96 | @author G. J. R@sc{OZAS} | |
97 | @author N. I. A@sc{DAMS IV} | |
98 | @author D. P. F@sc{RIEDMAN} | |
99 | @author E. K@sc{OHLBECKER} | |
100 | @author G. L. S@sc{TEELE} J@sc{R}. | |
101 | @author D. H. B@sc{ARTLEY} | |
102 | @author R. H@sc{ALSTEAD} | |
103 | @author D. O@sc{XLEY} | |
104 | @author G. J. S@sc{USSMAN} | |
105 | @author G. B@sc{ROOKS} | |
106 | @author C. H@sc{ANSON} | |
107 | @author K. M. P@sc{ITMAN} | |
108 | @author M. W@sc{AND} | |
109 | @author | |
110 | ||
111 | ||
112 | @c {\it Dedicated to the Memory of ALGOL 60} | |
113 | @i{Dedicated to the Memory of Robert Hieb} | |
114 | @c [For the macros in R5RS -RK] | |
115 | ||
116 | ||
117 | ||
118 | ||
119 | @unnumbered Summary | |
120 | ||
121 | ||
122 | The report gives a defining description of the programming language | |
123 | Scheme. Scheme is a statically scoped and properly tail-recursive | |
124 | dialect of the Lisp programming language invented by Guy Lewis | |
125 | Steele Jr.@: and Gerald Jay Sussman. It was designed to have an | |
126 | exceptionally clear and simple semantics and few different ways to | |
127 | form expressions. A wide variety of programming paradigms, including | |
128 | imperative, functional, and message passing styles, find convenient | |
129 | expression in Scheme. | |
130 | ||
131 | The introduction offers a brief history of the language and of | |
132 | the report. | |
133 | ||
134 | The first three chapters present the fundamental ideas of the | |
135 | language and describe the notational conventions used for describing the | |
136 | language and for writing programs in the language. | |
137 | ||
138 | Chapters @ref{Expressions} and @ref{Program structure} describe | |
139 | the syntax and semantics of expressions, programs, and definitions. | |
140 | ||
141 | Chapter @ref{Standard procedures} describes Scheme's built-in | |
142 | procedures, which include all of the language's data manipulation and | |
143 | input/output primitives. | |
144 | ||
145 | Chapter @ref{Formal syntax and semantics} provides a formal syntax for Scheme | |
146 | written in extended BNF, along with a formal denotational semantics. | |
147 | An example of the use of the language follows the formal syntax and | |
148 | semantics. | |
149 | ||
150 | The report concludes with a list of references and an | |
151 | alphabetic index. | |
152 | ||
153 | @ignore todo | |
154 | expand the summary so that it fills up the column. | |
155 | @end ignore | |
156 | ||
157 | ||
158 | @c \vfill | |
159 | @c \begin{center} | |
160 | @c {\large \bf | |
161 | @c *** DRAFT*** \\ | |
162 | @c %August 31, 1989 | |
163 | @c \today | |
164 | @c }\end{center} | |
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | @c \addvspace{3.5pt} % don't shrink this gap | |
171 | @c \renewcommand{\tocshrink}{-3.5pt} % value determined experimentally | |
172 | ||
173 | ||
174 | ||
175 | ||
176 | ||
177 | ||
178 | @page | |
179 | ||
180 | @end titlepage | |
181 | ||
182 | @c INFO first page | |
183 | @ifinfo | |
184 | ||
185 | @c First page | |
186 | ||
187 | @c \thispagestyle{empty} | |
188 | ||
189 | @c \todo{"another" report?} | |
190 | ||
191 | ||
192 | @node top, Introduction, (dir), (dir) | |
193 | @top Revised(5) Report on the Algorithmic Language Scheme | |
194 | ||
195 | @sp 1 | |
196 | ||
197 | ||
198 | @center @c begin-tabular | |
199 | @quotation | |
200 | @multitable @columnfractions 0.25 0.25 0.25 0.25 | |
201 | @item | |
202 | @center R@sc{ICHARD} K@sc{ELSEY}, W@sc{ILLIAM} C@sc{LINGER, AND} J@sc{ONATHAN} R@sc{EES} (@i{Editors}) | |
203 | @item H. A@sc{BELSON} @tab R. K. D@sc{YBVIG} @tab C. T. H@sc{AYNES} @tab G. J. R@sc{OZAS} | |
204 | @item N. I. A@sc{DAMS IV} @tab D. P. F@sc{RIEDMAN} @tab E. K@sc{OHLBECKER} @tab G. L. S@sc{TEELE} J@sc{R}. | |
205 | @item D. H. B@sc{ARTLEY} @tab R. H@sc{ALSTEAD} @tab D. O@sc{XLEY} @tab G. J. S@sc{USSMAN} | |
206 | @item G. B@sc{ROOKS} @tab C. H@sc{ANSON} @tab K. M. P@sc{ITMAN} @tab M. W@sc{AND} | |
207 | @item | |
208 | @end multitable | |
209 | @end quotation | |
210 | ||
211 | ||
212 | @sp 2 | |
213 | ||
214 | @c {\it Dedicated to the Memory of ALGOL 60} | |
215 | @i{Dedicated to the Memory of Robert Hieb} | |
216 | @c [For the macros in R5RS -RK] | |
217 | ||
218 | @sp 3 | |
219 | ||
220 | ||
221 | ||
222 | ||
223 | @majorheading Summary | |
224 | ||
225 | ||
226 | The report gives a defining description of the programming language | |
227 | Scheme. Scheme is a statically scoped and properly tail-recursive | |
228 | dialect of the Lisp programming language invented by Guy Lewis | |
229 | Steele Jr.@: and Gerald Jay Sussman. It was designed to have an | |
230 | exceptionally clear and simple semantics and few different ways to | |
231 | form expressions. A wide variety of programming paradigms, including | |
232 | imperative, functional, and message passing styles, find convenient | |
233 | expression in Scheme. | |
234 | ||
235 | The introduction offers a brief history of the language and of | |
236 | the report. | |
237 | ||
238 | The first three chapters present the fundamental ideas of the | |
239 | language and describe the notational conventions used for describing the | |
240 | language and for writing programs in the language. | |
241 | ||
242 | Chapters @ref{Expressions} and @ref{Program structure} describe | |
243 | the syntax and semantics of expressions, programs, and definitions. | |
244 | ||
245 | Chapter @ref{Standard procedures} describes Scheme's built-in | |
246 | procedures, which include all of the language's data manipulation and | |
247 | input/output primitives. | |
248 | ||
249 | Chapter @ref{Formal syntax and semantics} provides a formal syntax for Scheme | |
250 | written in extended BNF, along with a formal denotational semantics. | |
251 | An example of the use of the language follows the formal syntax and | |
252 | semantics. | |
253 | ||
254 | The report concludes with a list of references and an | |
255 | alphabetic index. | |
256 | ||
257 | @ignore todo | |
258 | expand the summary so that it fills up the column. | |
259 | @end ignore | |
260 | ||
261 | ||
262 | @c \vfill | |
263 | @c \begin{center} | |
264 | @c {\large \bf | |
265 | @c *** DRAFT*** \\ | |
266 | @c %August 31, 1989 | |
267 | @c \today | |
268 | @c }\end{center} | |
269 | ||
270 | ||
271 | ||
272 | ||
273 | ||
274 | @c \addvspace{3.5pt} % don't shrink this gap | |
275 | @c \renewcommand{\tocshrink}{-3.5pt} % value determined experimentally | |
276 | ||
277 | @unnumbered Contents | |
278 | ||
279 | @menu | |
280 | * Introduction:: | |
281 | * Overview of Scheme:: | |
282 | * Lexical conventions:: | |
283 | * Basic concepts:: | |
284 | * Expressions:: | |
285 | * Program structure:: | |
286 | * Standard procedures:: | |
287 | * Formal syntax and semantics:: | |
288 | * Notes:: | |
289 | * Additional material:: | |
290 | * Example:: | |
291 | * Bibliography:: | |
292 | * Index:: | |
293 | @end menu | |
294 | ||
295 | ||
296 | ||
297 | ||
298 | ||
299 | @page | |
300 | ||
301 | @end ifinfo | |
302 | ||
303 | ||
304 | @c @include{intro} | |
305 | @node Introduction, Overview of Scheme, top, top | |
306 | @unnumbered Introduction | |
307 | ||
308 | @menu | |
309 | * Background:: | |
310 | * Acknowledgements:: | |
311 | @end menu | |
312 | ||
313 | ||
314 | ||
315 | ||
316 | Programming languages should be designed not by piling feature on top of | |
317 | feature, but by removing the weaknesses and restrictions that make additional | |
318 | features appear necessary. Scheme demonstrates that a very small number | |
319 | of rules for forming expressions, with no restrictions on how they are | |
320 | composed, suffice to form a practical and efficient programming language | |
321 | that is flexible enough to support most of the major programming | |
322 | paradigms in use today. | |
323 | ||
324 | @c Scheme has influenced the evolution of Lisp. | |
325 | Scheme | |
326 | was one of the first programming languages to incorporate first class | |
327 | procedures as in the lambda calculus, thereby proving the usefulness of | |
328 | static scope rules and block structure in a dynamically typed language. | |
329 | Scheme was the first major dialect of Lisp to distinguish procedures | |
330 | from lambda expressions and symbols, to use a single lexical | |
331 | environment for all variables, and to evaluate the operator position | |
332 | of a procedure call in the same way as an operand position. By relying | |
333 | entirely on procedure calls to express iteration, Scheme emphasized the | |
334 | fact that tail-recursive procedure calls are essentially goto's that | |
335 | pass arguments. Scheme was the first widely used programming language to | |
336 | embrace first class escape procedures, from which all previously known | |
337 | sequential control structures can be synthesized. A subsequent | |
338 | version of Scheme introduced the concept of exact and inexact numbers, | |
339 | an extension of Common Lisp's generic arithmetic. | |
340 | More recently, Scheme became the first programming language to support | |
341 | hygienic macros, which permit the syntax of a block-structured language | |
342 | to be extended in a consistent and reliable manner. | |
343 | @c A few | |
344 | @c of these innovations have recently been incorporated into Common Lisp, while | |
345 | @c others remain to be adopted. | |
346 | ||
347 | @ignore todo | |
348 | Ramsdell: | |
349 | I would like to make a few comments on presentation. The most | |
350 | important comment is about section organization. Newspaper writers | |
351 | spend most of their time writing the first three paragraphs of any | |
352 | article. This part of the article is often the only part read by | |
353 | readers, and is important in enticing readers to continue. In the | |
354 | same way, The first page is most likely to be the only page read by | |
355 | many SIGPLAN readers. If I had my choice of what I would ask them to | |
356 | read, it would be the material in section 1.1, the Semantics section | |
357 | that notes that scheme is lexically scoped, tail recursive, weakly | |
358 | typed, ... etc. I would expand on the discussion on continuations, | |
359 | as they represent one important difference between Scheme and other | |
360 | languages. The introduction, with its history of scheme, its history | |
361 | of scheme reports and meetings, and acknowledgements giving names of | |
362 | people that the reader will not likely know, is not that one page I | |
363 | would like all to read. I suggest moving the history to the back of | |
364 | the report, and use the first couple of pages to convince the reader | |
365 | that the language documented in this report is worth studying. | |
366 | ||
367 | @end ignore | |
368 | ||
369 | ||
370 | @node Background, Acknowledgements, Introduction, Introduction | |
371 | @unnumberedsec Background | |
372 | ||
373 | ||
374 | The first description of Scheme was written in | |
375 | 1975 [Scheme75]. A revised report [Scheme78] | |
376 | @ignore todo | |
377 | italicize or not? | |
378 | @end ignore | |
379 | appeared in 1978, which described the evolution | |
380 | of the language as its MIT implementation was upgraded to support an | |
381 | innovative compiler [Rabbit]. Three distinct projects began in | |
382 | 1981 and 1982 to use variants of Scheme for courses at MIT, Yale, and | |
383 | Indiana University [Rees82], [MITScheme], [Scheme311]. An introductory | |
384 | computer science textbook using Scheme was published in | |
385 | 1984 [SICP]. | |
386 | ||
387 | @c \vest As might be expected of a language used primarily for education and | |
388 | @c research, Scheme has always evolved rapidly. This was no problem when | |
389 | @c Scheme was used only within MIT, but | |
390 | As Scheme became more widespread, | |
391 | local dialects began to diverge until students and researchers | |
392 | occasionally found it difficult to understand code written at other | |
393 | sites. | |
394 | Fifteen representatives of the major implementations of Scheme therefore | |
395 | met in October 1984 to work toward a better and more widely accepted | |
396 | standard for Scheme. | |
397 | @c Participating in this workshop were Hal Abelson, Norman Adams, David | |
398 | @c Bartley, Gary Brooks, William Clinger, Daniel Friedman, Robert Halstead, | |
399 | @c Chris Hanson, Christopher Haynes, Eugene Kohlbecker, Don Oxley, Jonathan Rees, | |
400 | @c Guillermo Rozas, Gerald Jay Sussman, and Mitchell Wand. Kent Pitman | |
401 | @c made valuable contributions to the agenda for the workshop but was | |
402 | @c unable to attend the sessions. | |
403 | ||
404 | @c Subsequent electronic mail discussions and committee work completed the | |
405 | @c definition of the language. | |
406 | @c Gerry Sussman drafted the section on numbers, Chris Hanson drafted the | |
407 | @c sections on characters and strings, and Gary Brooks and William Clinger | |
408 | @c drafted the sections on input and output. | |
409 | @c William Clinger recorded the decisions of the workshop and | |
410 | @c compiled the pieces into a coherent document. | |
411 | @c The ``Revised revised report on Scheme''~\cite{RRRS} | |
412 | Their report [RRRS] | |
413 | was published at MIT and Indiana University in the summer of 1985. | |
414 | Further revision took place in the spring of 1986 [R3RS], | |
415 | @c , again accomplished | |
416 | @c almost entirely by electronic mail, resulted in the present report. | |
417 | and in the spring of 1988 [R4RS]. | |
418 | The present report reflects further revisions agreed upon in a meeting | |
419 | at Xerox PARC in June 1992. | |
420 | ||
421 | @c \vest The number 3 in the title is part of the title, not a reference to | |
422 | @c a footnote. The word ``revised'' is raised to the third power because | |
423 | @c the report is a revision of a report that was already twice revised. | |
424 | ||
425 | @ignore todo | |
426 | Write an editors' note? | |
427 | @end ignore | |
428 | ||
429 | ||
430 | ||
431 | @sp 3 | |
432 | ||
433 | We intend this report to belong to the entire Scheme community, and so | |
434 | we grant permission to copy it in whole or in part without fee. In | |
435 | particular, we encourage implementors of Scheme to use this report as | |
436 | a starting point for manuals and other documentation, modifying it as | |
437 | necessary. | |
438 | ||
439 | ||
440 | ||
441 | ||
442 | @node Acknowledgements, , Background, Introduction | |
443 | @unnumberedsec Acknowledgements | |
444 | ||
445 | ||
446 | We would like to thank the following people for their help: Alan Bawden, Michael | |
447 | Blair, George Carrette, Andy Cromarty, Pavel Curtis, Jeff Dalton, Olivier Danvy, | |
448 | Ken Dickey, Bruce Duba, Marc Feeley, | |
449 | Andy Freeman, Richard Gabriel, Yekta G"ursel, Ken Haase, Robert | |
450 | Hieb, Paul Hudak, Morry Katz, Chris Lindblad, Mark Meyer, Jim Miller, Jim Philbin, | |
451 | John Ramsdell, Mike Shaff, Jonathan Shapiro, Julie Sussman, | |
452 | Perry Wagle, Daniel Weise, Henry Wu, and Ozan Yigit. | |
453 | We thank Carol Fessenden, Daniel | |
454 | Friedman, and Christopher Haynes for permission to use text from the Scheme 311 | |
455 | version 4 reference manual. We thank Texas Instruments, Inc. for permission to | |
456 | use text from the @emph{TI Scheme Language Reference Manual}[TImanual85]. | |
457 | We gladly acknowledge the influence of manuals for MIT Scheme[MITScheme], | |
458 | T[Rees84], Scheme 84[Scheme84],Common Lisp[CLtL], | |
459 | and Algol 60[Naur63]. | |
460 | ||
461 | We also thank Betty Dexter for the extreme effort she put into | |
462 | setting this report in @TeX{}, and Donald Knuth for designing the program | |
463 | that caused her troubles. | |
464 | ||
465 | The Artificial Intelligence Laboratory of the | |
466 | Massachusetts Institute of Technology, the Computer Science | |
467 | Department of Indiana University, the Computer and Information | |
468 | Sciences Department of the University of Oregon, and the NEC Research | |
469 | Institute supported the preparation of this report. Support for the MIT | |
470 | work was provided in part by | |
471 | the Advanced Research Projects Agency of the Department of Defense under Office | |
472 | of Naval Research contract N00014-80-C-0505. Support for the Indiana | |
473 | University work was provided by NSF grants NCS 83-04567 and NCS | |
474 | 83-03325. | |
475 | ||
476 | ||
477 | ||
478 | ||
479 | @sp 2 | |
480 | ||
481 | @c \clearchapterstar{Description of the language} %\unskip\vskip -2ex | |
482 | @c @include{struct} | |
483 | ||
484 | @c 1. Structure of the language | |
485 | ||
486 | @node Overview of Scheme, Lexical conventions, Introduction, top | |
487 | @chapter Overview of Scheme | |
488 | ||
489 | @menu | |
490 | * Semantics:: | |
491 | * Syntax:: | |
492 | * Notation and terminology:: | |
493 | @end menu | |
494 | ||
495 | ||
496 | @node Semantics, Syntax, Overview of Scheme, Overview of Scheme | |
497 | @section Semantics | |
498 | ||
499 | ||
500 | ||
501 | This section gives an overview of Scheme's semantics. A | |
502 | detailed informal semantics is the subject of | |
503 | chapters @ref{Basic concepts} through @ref{Standard procedures}. For reference | |
504 | purposes, section @ref{Formal semantics} provides a formal | |
505 | semantics of Scheme. | |
506 | ||
507 | Following Algol, Scheme is a statically scoped programming | |
508 | language. Each use of a variable is associated with a lexically | |
509 | apparent binding of that variable. | |
510 | ||
511 | Scheme has latent as opposed to manifest types. Types | |
512 | are associated with values (also called objects) rather than | |
513 | @cindex @w{object} | |
514 | with variables. (Some authors refer to languages with latent types as | |
515 | weakly typed or dynamically typed languages.) Other languages with | |
516 | latent types are APL, Snobol, and other dialects of Lisp. Languages | |
517 | with manifest types (sometimes referred to as strongly typed or | |
518 | statically typed languages) include Algol 60, Pascal, and C. | |
519 | ||
520 | All objects created in the course of a Scheme computation, including | |
521 | procedures and continuations, have unlimited extent. | |
522 | No Scheme object is ever destroyed. The reason that | |
523 | implementations of Scheme do not (usually!) run out of storage is that | |
524 | they are permitted to reclaim the storage occupied by an object if | |
525 | they can prove that the object cannot possibly matter to any future | |
526 | computation. Other languages in which most objects have unlimited | |
527 | extent include APL and other Lisp dialects. | |
528 | ||
529 | Implementations of Scheme are required to be properly tail-recursive. | |
530 | This allows the execution of an iterative computation in constant space, | |
531 | even if the iterative computation is described by a syntactically | |
532 | recursive procedure. Thus with a properly tail-recursive implementation, | |
533 | iteration can be expressed using the ordinary procedure-call | |
534 | mechanics, so that special iteration constructs are useful only as | |
535 | syntactic sugar. See section @ref{Proper tail recursion}. | |
536 | ||
537 | Scheme procedures are objects in their own right. Procedures can be | |
538 | created dynamically, stored in data structures, returned as results of | |
539 | procedures, and so on. Other languages with these properties include | |
540 | Common Lisp and ML. | |
541 | @ignore todo | |
542 | Rozas: Scheme had them first. | |
543 | @end ignore | |
544 | ||
545 | ||
546 | One distinguishing feature of Scheme is that continuations, which | |
547 | in most other languages only operate behind the scenes, also have | |
548 | ``first-class'' status. Continuations are useful for implementing a | |
549 | wide variety of advanced control constructs, including non-local exits, | |
550 | backtracking, and coroutines. See section @ref{Control features}. | |
551 | ||
552 | Arguments to Scheme procedures are always passed by value, which | |
553 | means that the actual argument expressions are evaluated before the | |
554 | procedure gains control, whether the procedure needs the result of the | |
555 | evaluation or not. ML, C, and APL are three other languages that always | |
556 | pass arguments by value. | |
557 | This is distinct from the lazy-evaluation semantics of Haskell, | |
558 | or the call-by-name semantics of Algol 60, where an argument | |
559 | expression is not evaluated unless its value is needed by the | |
560 | procedure. | |
561 | ||
562 | @ignore todo | |
563 | Lisp's call by value should be explained more | |
564 | accurately. What's funny is that all values are references. | |
565 | @end ignore | |
566 | ||
567 | ||
568 | Scheme's model of arithmetic is designed to remain as independent as | |
569 | possible of the particular ways in which numbers are represented within a | |
570 | computer. In Scheme, every integer is a rational number, every rational is a | |
571 | real, and every real is a complex number. Thus the distinction between integer | |
572 | and real arithmetic, so important to many programming languages, does not | |
573 | appear in Scheme. In its place is a distinction between exact arithmetic, | |
574 | which corresponds to the mathematical ideal, and inexact arithmetic on | |
575 | approximations. As in Common Lisp, exact arithmetic is not limited to | |
576 | integers. | |
577 | ||
578 | @node Syntax, Notation and terminology, Semantics, Overview of Scheme | |
579 | @section Syntax | |
580 | ||
581 | ||
582 | Scheme, like most dialects of Lisp, employs a fully parenthesized prefix | |
583 | notation for programs and (other) data; the grammar of Scheme generates a | |
584 | sublanguage of the language used for data. An important | |
585 | consequence of this simple, uniform representation is the susceptibility of | |
586 | Scheme programs and data to uniform treatment by other Scheme programs. | |
587 | For example, the @samp{eval} procedure evaluates a Scheme program expressed | |
588 | as data. | |
589 | ||
590 | The @samp{read} procedure performs syntactic as well as lexical decomposition of | |
591 | the data it reads. The @samp{read} procedure parses its input as data | |
592 | (section @pxref{External representation}), not as program. | |
593 | ||
594 | The formal syntax of Scheme is described in section @ref{Formal syntax}. | |
595 | ||
596 | ||
597 | @node Notation and terminology, , Syntax, Overview of Scheme | |
598 | @section Notation and terminology | |
599 | ||
600 | @menu | |
601 | * Primitive; library; and optional features:: | |
602 | * Error situations and unspecified behavior:: | |
603 | * Entry format:: | |
604 | * Evaluation examples:: | |
605 | * Naming conventions:: | |
606 | @end menu | |
607 | ||
608 | ||
609 | ||
610 | @node Primitive; library; and optional features, Error situations and unspecified behavior, Notation and terminology, Notation and terminology | |
611 | @subsection Primitive; library; and optional features | |
612 | ||
613 | ||
614 | ||
615 | It is required that every implementation of Scheme support all | |
616 | features that are not marked as being @dfn{optional}. Implementations are | |
617 | @cindex @w{optional} | |
618 | free to omit optional features of Scheme or to add extensions, | |
619 | provided the extensions are not in conflict with the language reported | |
620 | here. In particular, implementations must support portable code by | |
621 | providing a syntactic mode that preempts no lexical conventions of this | |
622 | report. | |
623 | ||
624 | To aid in understanding and implementing Scheme, some features are marked | |
625 | as @dfn{library}. These can be easily implemented in terms of the other, | |
626 | @cindex @w{library} | |
627 | primitive, features. They are redundant in the strict sense of | |
628 | the word, but they capture common patterns of usage, and are therefore | |
629 | provided as convenient abbreviations. | |
630 | ||
631 | @node Error situations and unspecified behavior, Entry format, Primitive; library; and optional features, Notation and terminology | |
632 | @subsection Error situations and unspecified behavior | |
633 | ||
634 | ||
635 | ||
636 | @cindex @w{error} | |
637 | When speaking of an error situation, this report uses the phrase ``an | |
638 | error is signalled'' to indicate that implementations must detect and | |
639 | report the error. If such wording does not appear in the discussion of | |
640 | an error, then implementations are not required to detect or report the | |
641 | error, though they are encouraged to do so. An error situation that | |
642 | implementations are not required to detect is usually referred to simply | |
643 | as ``an error.'' | |
644 | ||
645 | For example, it is an error for a procedure to be passed an argument that | |
646 | the procedure is not explicitly specified to handle, even though such | |
647 | domain errors are seldom mentioned in this report. Implementations may | |
648 | extend a procedure's domain of definition to include such arguments. | |
649 | ||
650 | This report uses the phrase ``may report a violation of an | |
651 | implementation restriction'' to indicate circumstances under which an | |
652 | implementation is permitted to report that it is unable to continue | |
653 | execution of a correct program because of some restriction imposed by the | |
654 | implementation. Implementation restrictions are of course discouraged, | |
655 | but implementations are encouraged to report violations of implementation | |
656 | restrictions. | |
657 | @cindex @w{implementation restriction} | |
658 | ||
659 | For example, an implementation may report a violation of an | |
660 | implementation restriction if it does not have enough storage to run a | |
661 | program. | |
662 | ||
663 | If the value of an expression is said to be ``unspecified,'' then | |
664 | the expression must evaluate to some object without signalling an error, | |
665 | but the value depends on the implementation; this report explicitly does | |
666 | not say what value should be returned. | |
667 | @cindex @w{unspecified} | |
668 | ||
669 | @ignore todo | |
670 | Talk about unspecified behavior vs. unspecified values. | |
671 | @end ignore | |
672 | ||
673 | ||
674 | @ignore todo | |
675 | Look at KMP's situations paper. | |
676 | @end ignore | |
677 | ||
678 | ||
679 | ||
680 | @node Entry format, Evaluation examples, Error situations and unspecified behavior, Notation and terminology | |
681 | @subsection Entry format | |
682 | ||
683 | ||
684 | Chapters @ref{Expressions} and @ref{Standard procedures} are organized | |
685 | into entries. Each entry describes one language feature or a group of | |
686 | related features, where a feature is either a syntactic construct or a | |
687 | built-in procedure. An entry begins with one or more header lines of the form | |
688 | ||
689 | ||
690 | @noindent | |
691 | @deffn {@var{category}} @var{template} | |
692 | ||
693 | @end deffn | |
694 | ||
695 | for required, primitive features, or | |
696 | ||
697 | ||
698 | @noindent | |
699 | @deffn {@var{qualifier} @var{category}} @var{template} | |
700 | ||
701 | @end deffn | |
702 | ||
703 | where @var{qualifier} is either ``library'' or ``optional'' as defined | |
704 | in section @ref{Primitive; library; and optional features}. | |
705 | ||
706 | If @var{category} is ``syntax'', the entry describes an expression | |
707 | type, and the template gives the syntax of the expression type. | |
708 | Components of expressions are designated by syntactic variables, which | |
709 | are written using angle brackets, for example, @r{<expression>}, | |
710 | @r{<variable>}. Syntactic variables should be understood to denote segments of | |
711 | program text; for example, @r{<expression>} stands for any string of | |
712 | characters which is a syntactically valid expression. The notation | |
713 | ||
714 | @format | |
715 | @r{<thing1>} @dots{} | |
716 | @end format | |
717 | ||
718 | indicates zero or more occurrences of a @r{<thing>}, and | |
719 | ||
720 | @format | |
721 | @r{<thing1>} @r{<thing2>} @dots{} | |
722 | @end format | |
723 | ||
724 | indicates one or more occurrences of a @r{<thing>}. | |
725 | ||
726 | If @var{category} is ``procedure'', then the entry describes a procedure, and | |
727 | the header line gives a template for a call to the procedure. Argument | |
728 | names in the template are @var{italicized}. Thus the header line | |
729 | ||
730 | ||
731 | @noindent | |
732 | @deffn {procedure} vector-ref @var{vector} @var{k} | |
733 | ||
734 | @end deffn | |
735 | ||
736 | indicates that the built-in procedure @t{vector-ref} takes | |
737 | two arguments, a vector @var{vector} and an exact non-negative integer | |
738 | @var{k} (see below). The header lines | |
739 | ||
740 | ||
741 | @noindent | |
742 | ||
743 | @deffn {procedure} make-vector @var{k} | |
744 | ||
745 | ||
746 | @deffnx {procedure} make-vector @var{k} @var{fill} | |
747 | ||
748 | @end deffn | |
749 | ||
750 | indicate that the @t{make-vector} procedure must be defined to take | |
751 | either one or two arguments. | |
752 | ||
753 | ||
754 | It is an error for an operation to be presented with an argument that it | |
755 | is not specified to handle. For succinctness, we follow the convention | |
756 | that if an argument name is also the name of a type listed in | |
757 | section @ref{Disjointness of types}, then that argument must be of the named type. | |
758 | For example, the header line for @t{vector-ref} given above dictates that the | |
759 | first argument to @t{vector-ref} must be a vector. The following naming | |
760 | conventions also imply type restrictions: | |
761 | @c \newcommand{\foo}[1]{\vr{#1}, \vri{#1}, $\ldots$ \vrj{#1}, $\ldots$} | |
762 | ||
763 | ||
764 | @center @c begin-tabular | |
765 | @quotation | |
766 | @table @asis | |
767 | @item @var{obj} | |
768 | any object | |
769 | @item @var{list}, @var{list1}, @dots{} @var{listj}, @dots{} | |
770 | list (see section @pxref{Pairs and lists}) | |
771 | @item @var{z}, @var{z1}, @dots{} @var{zj}, @dots{} | |
772 | complex number | |
773 | @item @var{x}, @var{x1}, @dots{} @var{xj}, @dots{} | |
774 | real number | |
775 | @item @var{y}, @var{y1}, @dots{} @var{yj}, @dots{} | |
776 | real number | |
777 | @item @var{q}, @var{q1}, @dots{} @var{qj}, @dots{} | |
778 | rational number | |
779 | @item @var{n}, @var{n1}, @dots{} @var{nj}, @dots{} | |
780 | integer | |
781 | @item @var{k}, @var{k1}, @dots{} @var{kj}, @dots{} | |
782 | exact non-negative integer | |
783 | @item | |
784 | @end table | |
785 | @end quotation | |
786 | ||
787 | ||
788 | ||
789 | ||
790 | @ignore todo | |
791 | Provide an example entry?? | |
792 | @end ignore | |
793 | ||
794 | ||
795 | ||
796 | @node Evaluation examples, Naming conventions, Entry format, Notation and terminology | |
797 | @subsection Evaluation examples | |
798 | ||
799 | ||
800 | The symbol ``@result{}'' used in program examples should be read | |
801 | ``evaluates to.'' For example, | |
802 | ||
803 | ||
804 | @example | |
805 | ||
806 | (* 5 8) ==> 40 | |
807 | ||
808 | @end example | |
809 | ||
810 | ||
811 | means that the expression @t{(* 5 8)} evaluates to the object @t{40}. | |
812 | Or, more precisely: the expression given by the sequence of characters | |
813 | ``@t{(* 5 8)}'' evaluates, in the initial environment, to an object | |
814 | that may be represented externally by the sequence of characters ``@t{40}''. See section @ref{External representations} for a discussion of external | |
815 | representations of objects. | |
816 | ||
817 | @node Naming conventions, , Evaluation examples, Notation and terminology | |
818 | @subsection Naming conventions | |
819 | ||
820 | ||
821 | By convention, the names of procedures that always return a boolean | |
822 | value usually end | |
823 | in ``@code{?}''. Such procedures are called predicates. | |
824 | @vindex @w{?} | |
825 | ||
826 | By convention, the names of procedures that store values into previously | |
827 | allocated locations (see section @pxref{Storage model}) usually end in | |
828 | ``@code{!}''. | |
829 | @vindex @w{!} | |
830 | Such procedures are called mutation procedures. | |
831 | By convention, the value returned by a mutation procedure is unspecified. | |
832 | ||
833 | By convention, ``@code{->}'' appears within the names of procedures that | |
834 | @vindex @w{->} | |
835 | take an object of one type and return an analogous object of another type. | |
836 | For example, @samp{list->vector} takes a list and returns a vector whose | |
837 | elements are the same as those of the list. | |
838 | ||
839 | ||
840 | ||
841 | @ignore todo | |
842 | Terms that need defining: thunk, command (what else?). | |
843 | @end ignore | |
844 | ||
845 | ||
846 | @c @include{lex} | |
847 | ||
848 | @c Lexical structure | |
849 | ||
850 | @c %\vfill\eject | |
851 | @node Lexical conventions, Basic concepts, Overview of Scheme, top | |
852 | @chapter Lexical conventions | |
853 | ||
854 | @menu | |
855 | * Identifiers:: | |
856 | * Whitespace and comments:: | |
857 | * Other notations:: | |
858 | @end menu | |
859 | ||
860 | ||
861 | This section gives an informal account of some of the lexical | |
862 | conventions used in writing Scheme programs. For a formal syntax of | |
863 | Scheme, see section @ref{Formal syntax}. | |
864 | ||
865 | Upper and lower case forms of a letter are never distinguished | |
866 | except within character and string constants. For example, @samp{Foo} is | |
867 | the same identifier as @samp{FOO}, and @t{#x1AB} is the same number as | |
868 | @t{#X1ab}. | |
869 | ||
870 | @node Identifiers, Whitespace and comments, Lexical conventions, Lexical conventions | |
871 | @section Identifiers | |
872 | ||
873 | ||
874 | ||
875 | Most identifiers allowed by other programming | |
876 | @cindex @w{identifier} | |
877 | languages are also acceptable to Scheme. The precise rules for forming | |
878 | identifiers vary among implementations of Scheme, but in all | |
879 | implementations a sequence of letters, digits, and ``extended alphabetic | |
880 | characters'' that begins with a character that cannot begin a number is | |
881 | an identifier. In addition, @code{+}, @code{-}, and @code{...} are identifiers. | |
882 | @vindex @w{...} | |
883 | @vindex @w{-} | |
884 | @vindex @w{+} | |
885 | Here are some examples of identifiers: | |
886 | ||
887 | ||
888 | @example | |
889 | ||
890 | lambda q | |
891 | list->vector soup | |
892 | + V17a | |
893 | <=? a34kTMNs | |
894 | the-word-recursion-has-many-meanings | |
895 | ||
896 | @end example | |
897 | ||
898 | ||
899 | Extended alphabetic characters may be used within identifiers as if | |
900 | they were letters. The following are extended alphabetic characters: | |
901 | ||
902 | ||
903 | @example | |
904 | ||
905 | ! $ % & * + - . / : < = > ? @@ ^ _ ~ | |
906 | @end example | |
907 | ||
908 | ||
909 | See section @ref{Lexical structure} for a formal syntax of identifiers. | |
910 | ||
911 | Identifiers have two uses within Scheme programs: | |
912 | ||
913 | ||
914 | @itemize @bullet | |
915 | ||
916 | @item | |
917 | Any identifier may be used as a variable | |
918 | or as a syntactic keyword | |
919 | (see sections @pxref{Variables; syntactic keywords; and regions} and @pxref{Macros}). | |
920 | ||
921 | @item | |
922 | When an identifier appears as a literal or within a literal | |
923 | (see section @pxref{Literal expressions}), it is being used to denote a @emph{symbol} | |
924 | (see section @pxref{Symbols}). | |
925 | ||
926 | ||
927 | @end itemize | |
928 | ||
929 | @cindex @w{syntactic keyword} | |
930 | @cindex @w{variable} | |
931 | ||
932 | @c \label{keywordsection} | |
933 | @c The following identifiers are syntactic keywords, and should not be used | |
934 | @c as variables: | |
935 | ||
936 | @c \begin{scheme} | |
937 | @c => do or | |
938 | @c and else quasiquote | |
939 | @c begin if quote | |
940 | @c case lambda set! | |
941 | @c cond let unquote | |
942 | @c define let* unquote-splicing | |
943 | @c delay letrec% | |
944 | @c \end{scheme} | |
945 | ||
946 | @c Some implementations allow all identifiers, including syntactic | |
947 | @c keywords, to be used as variables. This is a compatible extension to | |
948 | @c the language, but ambiguities in the language result when the | |
949 | @c restriction is relaxed, and the ways in which these ambiguities are | |
950 | @c resolved vary between implementations. | |
951 | ||
952 | ||
953 | @node Whitespace and comments, Other notations, Identifiers, Lexical conventions | |
954 | @section Whitespace and comments | |
955 | ||
956 | ||
957 | @dfn{Whitespace} characters are spaces and newlines. | |
958 | @cindex @w{Whitespace} | |
959 | (Implementations typically provide additional whitespace characters such | |
960 | as tab or page break.) Whitespace is used for improved readability and | |
961 | as necessary to separate tokens from each other, a token being an | |
962 | indivisible lexical unit such as an identifier or number, but is | |
963 | otherwise insignificant. Whitespace may occur between any two tokens, | |
964 | but not within a token. Whitespace may also occur inside a string, | |
965 | where it is significant. | |
966 | ||
967 | A semicolon (@t{;}) indicates the start of a | |
968 | comment. The comment continues to the | |
969 | @cindex @w{;} | |
970 | @cindex @w{comment} | |
971 | end of the line on which the semicolon appears. Comments are invisible | |
972 | to Scheme, but the end of the line is visible as whitespace. This | |
973 | prevents a comment from appearing in the middle of an identifier or | |
974 | number. | |
975 | ||
976 | ||
977 | @example | |
978 | ||
979 | ;;; The FACT procedure computes the factorial | |
980 | ;;; of a non-negative integer. | |
981 | (define fact | |
982 | (lambda (n) | |
983 | (if (= n 0) | |
984 | 1 ;Base case: return 1 | |
985 | (* n (fact (- n 1)))))) | |
986 | ||
987 | @end example | |
988 | ||
989 | ||
990 | ||
991 | @node Other notations, , Whitespace and comments, Lexical conventions | |
992 | @section Other notations | |
993 | ||
994 | ||
995 | @ignore todo | |
996 | Rewrite? | |
997 | @end ignore | |
998 | ||
999 | ||
1000 | For a description of the notations used for numbers, see | |
1001 | section @ref{Numbers}. | |
1002 | ||
1003 | ||
1004 | @table @t | |
1005 | ||
1006 | ||
1007 | @item @t{.@: + -} | |
1008 | These are used in numbers, and may also occur anywhere in an identifier | |
1009 | except as the first character. A delimited plus or minus sign by itself | |
1010 | is also an identifier. | |
1011 | A delimited period (not occurring within a number or identifier) is used | |
1012 | in the notation for pairs (section @pxref{Pairs and lists}), and to indicate a | |
1013 | rest-parameter in a formal parameter list (section @pxref{Procedures}). | |
1014 | A delimited sequence of three successive periods is also an identifier. | |
1015 | ||
1016 | @item @t{( )} | |
1017 | Parentheses are used for grouping and to notate lists | |
1018 | (section @pxref{Pairs and lists}). | |
1019 | ||
1020 | @item @t{'} | |
1021 | The single quote character is used to indicate literal data (section @pxref{Literal expressions}). | |
1022 | ||
1023 | @item @t{`} | |
1024 | The backquote character is used to indicate almost-constant | |
1025 | data (section @pxref{Quasiquotation}). | |
1026 | ||
1027 | @item @t{, ,@@} | |
1028 | The character comma and the sequence comma at-sign are used in conjunction | |
1029 | with backquote (section @pxref{Quasiquotation}). | |
1030 | ||
1031 | @item @t{"} | |
1032 | The double quote character is used to delimit strings (section @pxref{Strings}). | |
1033 | ||
1034 | @item \ | |
1035 | Backslash is used in the syntax for character constants | |
1036 | (section @pxref{Characters}) and as an escape character within string | |
1037 | constants (section @pxref{Strings}). | |
1038 | ||
1039 | @c A box used because \verb is not allowed in command arguments. | |
1040 | ||
1041 | @item @w{@t{[ ] @{ @} |}} | |
1042 | Left and right square brackets and curly braces and vertical bar | |
1043 | are reserved for possible future extensions to the language. | |
1044 | ||
1045 | @item # | |
1046 | Sharp sign is used for a variety of purposes depending on | |
1047 | the character that immediately follows it: | |
1048 | ||
1049 | @item @t{#t} @t{#f} | |
1050 | These are the boolean constants (section @pxref{Booleans}). | |
1051 | ||
1052 | @item #\ | |
1053 | This introduces a character constant (section @pxref{Characters}). | |
1054 | ||
1055 | @item #@t{(} | |
1056 | This introduces a vector constant (section @pxref{Vectors}). Vector constants | |
1057 | are terminated by @t{)} . | |
1058 | ||
1059 | @item @t{#e #i #b #o #d #x} | |
1060 | These are used in the notation for numbers (section @pxref{Syntax of numerical constants}). | |
1061 | ||
1062 | @end table | |
1063 | ||
1064 | ||
1065 | @c @include{basic} | |
1066 | ||
1067 | @c \vfill\eject | |
1068 | @node Basic concepts, Expressions, Lexical conventions, top | |
1069 | @chapter Basic concepts | |
1070 | ||
1071 | @menu | |
1072 | * Variables; syntactic keywords; and regions:: | |
1073 | * Disjointness of types:: | |
1074 | * External representations:: | |
1075 | * Storage model:: | |
1076 | * Proper tail recursion:: | |
1077 | @end menu | |
1078 | ||
1079 | ||
1080 | ||
1081 | @node Variables; syntactic keywords; and regions, Disjointness of types, Basic concepts, Basic concepts | |
1082 | @section Variables; syntactic keywords; and regions | |
1083 | ||
1084 | ||
1085 | ||
1086 | ||
1087 | An identifier may name a type of syntax, or it may name | |
1088 | @cindex @w{identifier} | |
1089 | a location where a value can be stored. An identifier that names a type | |
1090 | of syntax is called a @emph{syntactic keyword} | |
1091 | @cindex @w{syntactic keyword} | |
1092 | and is said to be @emph{bound} to that syntax. An identifier that names a | |
1093 | location is called a @emph{variable} and is said to be | |
1094 | @cindex @w{variable} | |
1095 | @emph{bound} to that location. The set of all visible | |
1096 | bindings in effect at some point in a program is | |
1097 | @cindex @w{binding} | |
1098 | known as the @emph{environment} in effect at that point. The value | |
1099 | stored in the location to which a variable is bound is called the | |
1100 | variable's value. By abuse of terminology, the variable is sometimes | |
1101 | said to name the value or to be bound to the value. This is not quite | |
1102 | accurate, but confusion rarely results from this practice. | |
1103 | ||
1104 | @ignore todo | |
1105 | Define ``assigned'' and ``unassigned'' perhaps? | |
1106 | @end ignore | |
1107 | ||
1108 | ||
1109 | @ignore todo | |
1110 | In programs without side effects, one can safely pretend that the | |
1111 | variables are bound directly to the arguments. Or: | |
1112 | In programs without @code{set!}, one can safely pretend that the | |
1113 | @vindex @w{set!} | |
1114 | variable is bound directly to the value. | |
1115 | @end ignore | |
1116 | ||
1117 | ||
1118 | Certain expression types are used to create new kinds of syntax | |
1119 | and bind syntactic keywords to those new syntaxes, while other | |
1120 | expression types create new locations and bind variables to those | |
1121 | locations. These expression types are called @emph{binding constructs}. | |
1122 | ||
1123 | @cindex @w{binding construct} | |
1124 | Those that bind syntactic keywords are listed in section @ref{Macros}. | |
1125 | The most fundamental of the variable binding constructs is the | |
1126 | @samp{lambda} expression, because all other variable binding constructs | |
1127 | can be explained in terms of @samp{lambda} expressions. The other | |
1128 | variable binding constructs are @samp{let}, @samp{let*}, @samp{letrec}, | |
1129 | and @samp{do} expressions (see sections @pxref{Procedures}, @pxref{Binding constructs}, and | |
1130 | @pxref{Iteration}). | |
1131 | ||
1132 | @c Note: internal definitions not mentioned here. | |
1133 | ||
1134 | Like Algol and Pascal, and unlike most other dialects of Lisp | |
1135 | except for Common Lisp, Scheme is a statically scoped language with | |
1136 | block structure. To each place where an identifier is bound in a program | |
1137 | there corresponds a @dfn{region} of the program text within which | |
1138 | @cindex @w{region} | |
1139 | the binding is visible. The region is determined by the particular | |
1140 | binding construct that establishes the binding; if the binding is | |
1141 | established by a @samp{lambda} expression, for example, then its region | |
1142 | is the entire @samp{lambda} expression. Every mention of an identifier | |
1143 | refers to the binding of the identifier that established the | |
1144 | innermost of the regions containing the use. If there is no binding of | |
1145 | the identifier whose region contains the use, then the use refers to the | |
1146 | binding for the variable in the top level environment, if any | |
1147 | (chapters @pxref{Expressions} and @pxref{Standard procedures}); if there is no | |
1148 | binding for the identifier, | |
1149 | it is said to be @dfn{unbound}. | |
1150 | @cindex @w{top level environment} | |
1151 | @cindex @w{bound} | |
1152 | @cindex @w{unbound} | |
1153 | ||
1154 | @ignore todo | |
1155 | Mention that some implementations have multiple top level environments? | |
1156 | @end ignore | |
1157 | ||
1158 | ||
1159 | @ignore todo | |
1160 | Pitman sez: needs elaboration in case of @t{(let ...)} | |
1161 | @end ignore | |
1162 | ||
1163 | ||
1164 | @ignore todo | |
1165 | Pitman asks: say something about vars created after scheme starts? | |
1166 | @t{(define x 3) (define (f) x) (define (g) y) (define y 4)} | |
1167 | Clinger replies: The language was explicitly | |
1168 | designed to permit a view in which no variables are created after | |
1169 | Scheme starts. In files, you can scan out the definitions beforehand. | |
1170 | I think we're agreed on the principle that interactive use should | |
1171 | approximate that behavior as closely as possible, though we don't yet | |
1172 | agree on which programming environment provides the best approximation. | |
1173 | @end ignore | |
1174 | ||
1175 | ||
1176 | @node Disjointness of types, External representations, Variables; syntactic keywords; and regions, Basic concepts | |
1177 | @section Disjointness of types | |
1178 | ||
1179 | ||
1180 | ||
1181 | No object satisfies more than one of the following predicates: | |
1182 | ||
1183 | ||
1184 | @example | |
1185 | ||
1186 | boolean? pair? | |
1187 | symbol? number? | |
1188 | char? string? | |
1189 | vector? port? | |
1190 | procedure? | |
1191 | ||
1192 | @end example | |
1193 | ||
1194 | ||
1195 | These predicates define the types @emph{boolean}, @emph{pair}, @emph{symbol}, @emph{number}, @emph{char} (or @emph{character}), @emph{string}, @emph{vector}, @emph{port}, and @emph{procedure}. The empty list is a special | |
1196 | object of its own type; it satisfies none of the above predicates. | |
1197 | ||
1198 | @vindex symbol? | |
1199 | @vindex pair? | |
1200 | @vindex boolean? | |
1201 | @cindex @w{type} | |
1202 | ||
1203 | @vindex vector? | |
1204 | @vindex string? | |
1205 | @vindex char? | |
1206 | @vindex number? | |
1207 | ||
1208 | @cindex @w{empty list} | |
1209 | @vindex procedure? | |
1210 | @vindex port? | |
1211 | ||
1212 | Although there is a separate boolean type, | |
1213 | any Scheme value can be used as a boolean value for the purpose of a | |
1214 | conditional test. As explained in section @ref{Booleans}, all | |
1215 | values count as true in such a test except for @t{#f}. | |
1216 | @c and possibly the empty list. | |
1217 | @c The only value that is guaranteed to count as | |
1218 | @c false is \schfalse{}. It is explicitly unspecified whether the empty list | |
1219 | @c counts as true or as false. | |
1220 | This report uses the word ``true'' to refer to any | |
1221 | Scheme value except @t{#f}, and the word ``false'' to refer to | |
1222 | @t{#f}. | |
1223 | @cindex @w{false} | |
1224 | @cindex @w{true} | |
1225 | ||
1226 | @node External representations, Storage model, Disjointness of types, Basic concepts | |
1227 | @section External representations | |
1228 | ||
1229 | ||
1230 | ||
1231 | An important concept in Scheme (and Lisp) is that of the @emph{external | |
1232 | representation} of an object as a sequence of characters. For example, | |
1233 | an external representation of the integer 28 is the sequence of | |
1234 | characters ``@t{28}'', and an external representation of a list consisting | |
1235 | of the integers 8 and 13 is the sequence of characters ``@t{(8 13)}''. | |
1236 | ||
1237 | The external representation of an object is not necessarily unique. The | |
1238 | integer 28 also has representations ``@t{#e28.000}'' and ``@t{#x1c}'', and the | |
1239 | list in the previous paragraph also has the representations ``@t{( 08 13 | |
1240 | )}'' and ``@t{(8 .@: (13 .@: ()))}'' (see section @pxref{Pairs and lists}). | |
1241 | ||
1242 | Many objects have standard external representations, but some, such as | |
1243 | procedures, do not have standard representations (although particular | |
1244 | implementations may define representations for them). | |
1245 | ||
1246 | An external representation may be written in a program to obtain the | |
1247 | corresponding object (see @samp{quote}, section @pxref{Literal expressions}). | |
1248 | ||
1249 | External representations can also be used for input and output. The | |
1250 | procedure @samp{read} (section @pxref{Input}) parses external | |
1251 | representations, and the procedure @samp{write} (section @pxref{Output}) | |
1252 | generates them. Together, they provide an elegant and powerful | |
1253 | input/output facility. | |
1254 | ||
1255 | Note that the sequence of characters ``@t{(+ 2 6)}'' is @emph{not} an | |
1256 | external representation of the integer 8, even though it @emph{is} an | |
1257 | expression evaluating to the integer 8; rather, it is an external | |
1258 | representation of a three-element list, the elements of which are the symbol | |
1259 | @t{+} and the integers 2 and 6. Scheme's syntax has the property that | |
1260 | any sequence of characters that is an expression is also the external | |
1261 | representation of some object. This can lead to confusion, since it may | |
1262 | not be obvious out of context whether a given sequence of characters is | |
1263 | intended to denote data or program, but it is also a source of power, | |
1264 | since it facilitates writing programs such as interpreters and | |
1265 | compilers that treat programs as data (or vice versa). | |
1266 | ||
1267 | The syntax of external representations of various kinds of objects | |
1268 | accompanies the description of the primitives for manipulating the | |
1269 | objects in the appropriate sections of chapter @ref{Standard procedures}. | |
1270 | ||
1271 | @node Storage model, Proper tail recursion, External representations, Basic concepts | |
1272 | @section Storage model | |
1273 | ||
1274 | ||
1275 | ||
1276 | Variables and objects such as pairs, vectors, and strings implicitly | |
1277 | denote locations or sequences of locations. A string, for | |
1278 | @cindex @w{location} | |
1279 | example, denotes as many locations as there are characters in the string. | |
1280 | (These locations need not correspond to a full machine word.) A new value may be | |
1281 | stored into one of these locations using the @t{string-set!} procedure, but | |
1282 | the string continues to denote the same locations as before. | |
1283 | ||
1284 | An object fetched from a location, by a variable reference or by | |
1285 | a procedure such as @samp{car}, @samp{vector-ref}, or @samp{string-ref}, is | |
1286 | equivalent in the sense of @code{eqv?} | |
1287 | @c and \ide{eq?} ?? | |
1288 | (section @pxref{Equivalence predicates}) | |
1289 | @vindex @w{eqv?} | |
1290 | to the object last stored in the location before the fetch. | |
1291 | ||
1292 | Every location is marked to show whether it is in use. | |
1293 | No variable or object ever refers to a location that is not in use. | |
1294 | Whenever this report speaks of storage being allocated for a variable | |
1295 | or object, what is meant is that an appropriate number of locations are | |
1296 | chosen from the set of locations that are not in use, and the chosen | |
1297 | locations are marked to indicate that they are now in use before the variable | |
1298 | or object is made to denote them. | |
1299 | ||
1300 | In many systems it is desirable for constants (i.e. the values of | |
1301 | @cindex @w{constant} | |
1302 | literal expressions) to reside in read-only-memory. To express this, it is | |
1303 | convenient to imagine that every object that denotes locations is associated | |
1304 | with a flag telling whether that object is mutable or | |
1305 | @cindex @w{mutable} | |
1306 | immutable. In such systems literal constants and the strings | |
1307 | @cindex @w{immutable} | |
1308 | returned by @code{symbol->string} are immutable objects, while all objects | |
1309 | @vindex @w{symbol->string} | |
1310 | created by the other procedures listed in this report are mutable. It is an | |
1311 | error to attempt to store a new value into a location that is denoted by an | |
1312 | immutable object. | |
1313 | ||
1314 | @node Proper tail recursion, , Storage model, Basic concepts | |
1315 | @section Proper tail recursion | |
1316 | ||
1317 | ||
1318 | ||
1319 | Implementations of Scheme are required to be | |
1320 | @emph{properly tail-recursive}. | |
1321 | @cindex @w{proper tail recursion} | |
1322 | Procedure calls that occur in certain syntactic | |
1323 | contexts defined below are `tail calls'. A Scheme implementation is | |
1324 | properly tail-recursive if it supports an unbounded number of active | |
1325 | tail calls. A call is @emph{active} if the called procedure may still | |
1326 | return. Note that this includes calls that may be returned from either | |
1327 | by the current continuation or by continuations captured earlier by | |
1328 | @samp{call-with-current-continuation} that are later invoked. | |
1329 | In the absence of captured continuations, calls could | |
1330 | return at most once and the active calls would be those that had not | |
1331 | yet returned. | |
1332 | A formal definition of proper tail recursion can be found | |
1333 | in [propertailrecursion]. | |
1334 | ||
1335 | ||
1336 | @quotation | |
1337 | @emph{Rationale:} | |
1338 | ||
1339 | Intuitively, no space is needed for an active tail call because the | |
1340 | continuation that is used in the tail call has the same semantics as the | |
1341 | continuation passed to the procedure containing the call. Although an improper | |
1342 | implementation might use a new continuation in the call, a return | |
1343 | to this new continuation would be followed immediately by a return | |
1344 | to the continuation passed to the procedure. A properly tail-recursive | |
1345 | implementation returns to that continuation directly. | |
1346 | ||
1347 | Proper tail recursion was one of the central ideas in Steele and | |
1348 | Sussman's original version of Scheme. Their first Scheme interpreter | |
1349 | implemented both functions and actors. Control flow was expressed using | |
1350 | actors, which differed from functions in that they passed their results | |
1351 | on to another actor instead of returning to a caller. In the terminology | |
1352 | of this section, each actor finished with a tail call to another actor. | |
1353 | ||
1354 | Steele and Sussman later observed that in their interpreter the code | |
1355 | for dealing with actors was identical to that for functions and thus | |
1356 | there was no need to include both in the language. | |
1357 | ||
1358 | @end quotation | |
1359 | ||
1360 | ||
1361 | A @emph{tail call} is a procedure call that occurs | |
1362 | @cindex @w{tail call} | |
1363 | in a @emph{tail context}. Tail contexts are defined inductively. Note | |
1364 | that a tail context is always determined with respect to a particular lambda | |
1365 | expression. | |
1366 | ||
1367 | ||
1368 | ||
1369 | @itemize @bullet | |
1370 | ||
1371 | @item | |
1372 | The last expression within the body of a lambda expression, | |
1373 | shown as @r{<tail expression>} below, occurs in a tail context. | |
1374 | ||
1375 | @format | |
1376 | @t{(lambda <formals> | |
1377 | <definition>* <expression>* <tail expression>) | |
1378 | } | |
1379 | ||
1380 | @end format | |
1381 | ||
1382 | ||
1383 | ||
1384 | @item | |
1385 | If one of the following expressions is in a tail context, | |
1386 | then the subexpressions shown as <tail expression> are in a tail context. | |
1387 | These were derived from rules in the grammar given in | |
1388 | chapter @ref{Formal syntax and semantics} by replacing some occurrences of <expression> | |
1389 | with <tail expression>. Only those rules that contain tail contexts | |
1390 | are shown here. | |
1391 | ||
1392 | ||
1393 | @format | |
1394 | @t{(if <expression> <tail expression> <tail expression>) | |
1395 | (if <expression> <tail expression>) | |
1396 | ||
1397 | (cond <cond clause>+) | |
1398 | (cond <cond clause>* (else <tail sequence>)) | |
1399 | ||
1400 | (case <expression> | |
1401 | <case clause>+) | |
1402 | (case <expression> | |
1403 | <case clause>* | |
1404 | (else <tail sequence>)) | |
1405 | ||
1406 | (and <expression>* <tail expression>) | |
1407 | (or <expression>* <tail expression>) | |
1408 | ||
1409 | (let (<binding spec>*) <tail body>) | |
1410 | (let <variable> (<binding spec>*) <tail body>) | |
1411 | (let* (<binding spec>*) <tail body>) | |
1412 | (letrec (<binding spec>*) <tail body>) | |
1413 | ||
1414 | (let-syntax (<syntax spec>*) <tail body>) | |
1415 | (letrec-syntax (<syntax spec>*) <tail body>) | |
1416 | ||
1417 | (begin <tail sequence>) | |
1418 | ||
1419 | (do (<iteration spec>*) | |
1420 | (<test> <tail sequence>) | |
1421 | <expression>*) | |
1422 | ||
1423 | @r{where} | |
1424 | ||
1425 | <cond clause> --> (<test> <tail sequence>) | |
1426 | <case clause> --> ((<datum>*) <tail sequence>) | |
1427 | ||
1428 | <tail body> --> <definition>* <tail sequence> | |
1429 | <tail sequence> --> <expression>* <tail expression> | |
1430 | } | |
1431 | ||
1432 | @end format | |
1433 | ||
1434 | ||
1435 | ||
1436 | @item | |
1437 | If a @samp{cond} expression is in a tail context, and has a clause of | |
1438 | the form @samp{(@r{<expression1>} => @r{<expression2>})} | |
1439 | then the (implied) call to | |
1440 | the procedure that results from the evaluation of @r{<expression2>} is in a | |
1441 | tail context. @r{<expression2>} itself is not in a tail context. | |
1442 | ||
1443 | ||
1444 | @end itemize | |
1445 | ||
1446 | ||
1447 | Certain built-in procedures are also required to perform tail calls. | |
1448 | The first argument passed to @code{apply} and to | |
1449 | @vindex @w{apply} | |
1450 | @code{call-with-current-continuation}, and the second argument passed to | |
1451 | @vindex @w{call-with-current-continuation} | |
1452 | @code{call-with-values}, must be called via a tail call. | |
1453 | @vindex @w{call-with-values} | |
1454 | Similarly, @code{eval} must evaluate its argument as if it | |
1455 | @vindex @w{eval} | |
1456 | were in tail position within the @code{eval} procedure. | |
1457 | @vindex @w{eval} | |
1458 | ||
1459 | In the following example the only tail call is the call to @samp{f}. | |
1460 | None of the calls to @samp{g} or @samp{h} are tail calls. The reference to | |
1461 | @samp{x} is in a tail context, but it is not a call and thus is not a | |
1462 | tail call. | |
1463 | ||
1464 | @example | |
1465 | ||
1466 | (lambda () | |
1467 | (if (g) | |
1468 | (let ((x (h))) | |
1469 | x) | |
1470 | (and (g) (f)))) | |
1471 | ||
1472 | @end example | |
1473 | ||
1474 | ||
1475 | ||
1476 | @quotation | |
1477 | @emph{Note:} | |
1478 | Implementations are allowed, but not required, to | |
1479 | recognize that some non-tail calls, such as the call to @samp{h} | |
1480 | above, can be evaluated as though they were tail calls. | |
1481 | In the example above, the @samp{let} expression could be compiled | |
1482 | as a tail call to @samp{h}. (The possibility of @samp{h} returning | |
1483 | an unexpected number of values can be ignored, because in that | |
1484 | case the effect of the @samp{let} is explicitly unspecified and | |
1485 | implementation-dependent.) | |
1486 | @end quotation | |
1487 | ||
1488 | ||
1489 | ||
1490 | @c @include{expr} | |
1491 | ||
1492 | @c \vfill\eject | |
1493 | @node Expressions, Program structure, Basic concepts, top | |
1494 | @chapter Expressions | |
1495 | ||
1496 | @menu | |
1497 | * Primitive expression types:: | |
1498 | * Derived expression types:: | |
1499 | * Macros:: | |
1500 | @end menu | |
1501 | ||
1502 | ||
1503 | ||
1504 | @c \newcommand{\syntax}{{\em Syntax: }} | |
1505 | @c \newcommand{\semantics}{{\em Semantics: }} | |
1506 | ||
1507 | @c [Deleted for R5RS because of multiple-value returns. -RK] | |
1508 | @c A Scheme expression is a construct that returns a value, such as a | |
1509 | @c variable reference, literal, procedure call, or conditional. | |
1510 | ||
1511 | Expression types are categorized as @emph{primitive} or @emph{derived}. | |
1512 | Primitive expression types include variables and procedure calls. | |
1513 | Derived expression types are not semantically primitive, but can instead | |
1514 | be defined as macros. | |
1515 | With the exception of @samp{quasiquote}, whose macro definition is complex, | |
1516 | the derived expressions are classified as library features. | |
1517 | Suitable definitions are given in section @ref{Derived expression type}. | |
1518 | ||
1519 | @node Primitive expression types, Derived expression types, Expressions, Expressions | |
1520 | @section Primitive expression types | |
1521 | ||
1522 | @menu | |
1523 | * Variable references:: | |
1524 | * Literal expressions:: | |
1525 | * Procedure calls:: | |
1526 | * Procedures:: | |
1527 | * Conditionals:: | |
1528 | * Assignments:: | |
1529 | @end menu | |
1530 | ||
1531 | ||
1532 | ||
1533 | @node Variable references, Literal expressions, Primitive expression types, Primitive expression types | |
1534 | @subsection Variable references | |
1535 | ||
1536 | ||
1537 | ||
1538 | @deffn {syntax} @r{<variable>} | |
1539 | ||
1540 | ||
1541 | An expression consisting of a variable | |
1542 | @cindex @w{variable} | |
1543 | (section @pxref{Variables; syntactic keywords; and regions}) is a variable reference. The value of | |
1544 | the variable reference is the value stored in the location to which the | |
1545 | variable is bound. It is an error to reference an | |
1546 | unbound variable. | |
1547 | @cindex @w{unbound} | |
1548 | ||
1549 | ||
1550 | @format | |
1551 | @t{(define x 28) | |
1552 | x ==> 28 | |
1553 | } | |
1554 | @end format | |
1555 | ||
1556 | @end deffn | |
1557 | ||
1558 | @node Literal expressions, Procedure calls, Variable references, Primitive expression types | |
1559 | @subsection Literal expressions | |
1560 | ||
1561 | ||
1562 | ||
1563 | ||
1564 | @deffn {syntax} quote @r{<datum>} | |
1565 | ||
1566 | @deffnx {syntax} @t{'}@r{<datum>} | |
1567 | ||
1568 | ||
1569 | @deffnx {syntax} @r{<constant>} | |
1570 | ||
1571 | ||
1572 | @samp{(quote @r{<datum>})} evaluates to @r{<datum>}. | |
1573 | @cindex @w{'} | |
1574 | @r{<Datum>} | |
1575 | may be any external representation of a Scheme object (see | |
1576 | section @pxref{External representations}). This notation is used to include literal | |
1577 | constants in Scheme code. | |
1578 | ||
1579 | ||
1580 | @format | |
1581 | @t{ | |
1582 | (quote a) ==> a | |
1583 | (quote #(a b c)) ==> #(a b c) | |
1584 | (quote (+ 1 2)) ==> (+ 1 2) | |
1585 | } | |
1586 | @end format | |
1587 | ||
1588 | ||
1589 | @samp{(quote @r{<datum>})} may be abbreviated as | |
1590 | @t{'}@r{<datum>}. The two notations are equivalent in all | |
1591 | respects. | |
1592 | ||
1593 | ||
1594 | @format | |
1595 | @t{'a ==> a | |
1596 | '#(a b c) ==> #(a b c) | |
1597 | '() ==> () | |
1598 | '(+ 1 2) ==> (+ 1 2) | |
1599 | '(quote a) ==> (quote a) | |
1600 | ''a ==> (quote a) | |
1601 | } | |
1602 | @end format | |
1603 | ||
1604 | ||
1605 | Numerical constants, string constants, character constants, and boolean | |
1606 | constants evaluate ``to themselves''; they need not be quoted. | |
1607 | ||
1608 | ||
1609 | @format | |
1610 | @t{'"abc" ==> "abc" | |
1611 | "abc" ==> "abc" | |
1612 | '145932 ==> 145932 | |
1613 | 145932 ==> 145932 | |
1614 | '#t ==> #t | |
1615 | #t ==> #t | |
1616 | } | |
1617 | @end format | |
1618 | ||
1619 | ||
1620 | As noted in section @ref{Storage model}, it is an error to alter a constant | |
1621 | (i.e. the value of a literal expression) using a mutation procedure like | |
1622 | @samp{set-car!} or @samp{string-set!}. | |
1623 | ||
1624 | @end deffn | |
1625 | ||
1626 | ||
1627 | @node Procedure calls, Procedures, Literal expressions, Primitive expression types | |
1628 | @subsection Procedure calls | |
1629 | ||
1630 | ||
1631 | ||
1632 | @deffn {syntax} @r{<operator>} @r{<operand1>} @dots{}, | |
1633 | ||
1634 | ||
1635 | A procedure call is written by simply enclosing in parentheses | |
1636 | expressions for the procedure to be called and the arguments to be | |
1637 | passed to it. The operator and operand expressions are evaluated (in an | |
1638 | unspecified order) and the resulting procedure is passed the resulting | |
1639 | arguments. | |
1640 | @cindex @w{procedure call} | |
1641 | @cindex @w{call} | |
1642 | ||
1643 | @format | |
1644 | @t{ | |
1645 | (+ 3 4) ==> 7 | |
1646 | ((if #f + *) 3 4) ==> 12 | |
1647 | } | |
1648 | @end format | |
1649 | ||
1650 | ||
1651 | A number of procedures are available as the values of variables in the | |
1652 | initial environment; for example, the addition and multiplication | |
1653 | procedures in the above examples are the values of the variables @samp{+} | |
1654 | and @samp{*}. New procedures are created by evaluating lambda expressions | |
1655 | (see section @pxref{Procedures}). | |
1656 | @ignore todo | |
1657 | At Friedman's request, flushed mention of other ways. | |
1658 | @end ignore | |
1659 | ||
1660 | @c or definitions (see section~\ref{define}). | |
1661 | ||
1662 | Procedure calls may return any number of values (see @code{values} in | |
1663 | @vindex @w{values} | |
1664 | section @pxref{Control features}). With the exception of @samp{values} | |
1665 | the procedures available in the initial environment return one | |
1666 | value or, for procedures such as @samp{apply}, pass on the values returned | |
1667 | by a call to one of their arguments. | |
1668 | ||
1669 | Procedure calls are also called @emph{combinations}. | |
1670 | ||
1671 | @cindex @w{combination} | |
1672 | ||
1673 | ||
1674 | @quotation | |
1675 | @emph{Note:} In contrast to other dialects of Lisp, the order of | |
1676 | evaluation is unspecified, and the operator expression and the operand | |
1677 | expressions are always evaluated with the same evaluation rules. | |
1678 | @end quotation | |
1679 | ||
1680 | ||
1681 | ||
1682 | @quotation | |
1683 | @emph{Note:} | |
1684 | Although the order of evaluation is otherwise unspecified, the effect of | |
1685 | any concurrent evaluation of the operator and operand expressions is | |
1686 | constrained to be consistent with some sequential order of evaluation. | |
1687 | The order of evaluation may be chosen differently for each procedure call. | |
1688 | @end quotation | |
1689 | ||
1690 | ||
1691 | ||
1692 | @quotation | |
1693 | @emph{Note:} In many dialects of Lisp, the empty combination, @t{()}, is a legitimate expression. In Scheme, combinations must have at | |
1694 | least one subexpression, so @t{()} is not a syntactically valid | |
1695 | expression. | |
1696 | @ignore todo | |
1697 | Dybvig: ``it should be obvious from the syntax.'' | |
1698 | @end ignore | |
1699 | ||
1700 | @end quotation | |
1701 | ||
1702 | ||
1703 | @ignore todo | |
1704 | Freeman: | |
1705 | I think an explanation as to why evaluation order is not specified | |
1706 | should be included. It should not include any reference to parallel | |
1707 | evaluation. Does any existing compiler generate better code because | |
1708 | the evaluation order is unspecified? Clinger: yes: T3, MacScheme v2, | |
1709 | probably MIT Scheme and Chez Scheme. But that's not the main reason | |
1710 | for leaving the order unspecified. | |
1711 | @end ignore | |
1712 | ||
1713 | ||
1714 | @end deffn | |
1715 | ||
1716 | ||
1717 | @node Procedures, Conditionals, Procedure calls, Primitive expression types | |
1718 | @subsection Procedures | |
1719 | ||
1720 | ||
1721 | ||
1722 | ||
1723 | @deffn {syntax} lambda @r{<formals>} @r{<body>} | |
1724 | ||
1725 | @emph{Syntax:} | |
1726 | @r{<Formals>} should be a formal arguments list as described below, | |
1727 | and @r{<body>} should be a sequence of one or more expressions. | |
1728 | ||
1729 | @emph{Semantics:} | |
1730 | A lambda expression evaluates to a procedure. The environment in | |
1731 | effect when the lambda expression was evaluated is remembered as part of the | |
1732 | procedure. When the procedure is later called with some actual | |
1733 | arguments, the environment in which the lambda expression was evaluated will | |
1734 | be extended by binding the variables in the formal argument list to | |
1735 | fresh locations, the corresponding actual argument values will be stored | |
1736 | in those locations, and the expressions in the body of the lambda expression | |
1737 | will be evaluated sequentially in the extended environment. | |
1738 | The result(s) of the last expression in the body will be returned as | |
1739 | the result(s) of the procedure call. | |
1740 | ||
1741 | ||
1742 | @format | |
1743 | @t{(lambda (x) (+ x x)) ==> @emph{}a procedure | |
1744 | ((lambda (x) (+ x x)) 4) ==> 8 | |
1745 | ||
1746 | (define reverse-subtract | |
1747 | (lambda (x y) (- y x))) | |
1748 | (reverse-subtract 7 10) ==> 3 | |
1749 | ||
1750 | (define add4 | |
1751 | (let ((x 4)) | |
1752 | (lambda (y) (+ x y)))) | |
1753 | (add4 6) ==> 10 | |
1754 | } | |
1755 | @end format | |
1756 | ||
1757 | ||
1758 | @r{<Formals>} should have one of the following forms: | |
1759 | ||
1760 | ||
1761 | ||
1762 | @itemize @bullet | |
1763 | ||
1764 | @item | |
1765 | @t{(@r{<variable1>} @dots{},)}: | |
1766 | The procedure takes a fixed number of arguments; when the procedure is | |
1767 | called, the arguments will be stored in the bindings of the | |
1768 | corresponding variables. | |
1769 | ||
1770 | @item | |
1771 | @r{<variable>}: | |
1772 | The procedure takes any number of arguments; when the procedure is | |
1773 | called, the sequence of actual arguments is converted into a newly | |
1774 | allocated list, and the list is stored in the binding of the | |
1775 | @r{<variable>}. | |
1776 | ||
1777 | @item | |
1778 | @t{(@r{<variable1>} @dots{}, @r{<variable_n>} @b{.} | |
1779 | @r{<variable_n+1>})}: | |
1780 | If a space-delimited period precedes the last variable, then | |
1781 | the procedure takes n or more arguments, where n is the | |
1782 | number of formal arguments before the period (there must | |
1783 | be at least one). | |
1784 | The value stored in the binding of the last variable will be a | |
1785 | newly allocated | |
1786 | list of the actual arguments left over after all the other actual | |
1787 | arguments have been matched up against the other formal arguments. | |
1788 | ||
1789 | @end itemize | |
1790 | ||
1791 | ||
1792 | It is an error for a @r{<variable>} to appear more than once in | |
1793 | @r{<formals>}. | |
1794 | ||
1795 | ||
1796 | @format | |
1797 | @t{((lambda x x) 3 4 5 6) ==> (3 4 5 6) | |
1798 | ((lambda (x y . z) z) | |
1799 | 3 4 5 6) ==> (5 6) | |
1800 | } | |
1801 | @end format | |
1802 | ||
1803 | ||
1804 | Each procedure created as the result of evaluating a lambda expression is | |
1805 | (conceptually) tagged | |
1806 | with a storage location, in order to make @code{eqv?} and | |
1807 | @vindex @w{eqv?} | |
1808 | @code{eq?} work on procedures (see section @pxref{Equivalence predicates}). | |
1809 | @vindex @w{eq?} | |
1810 | ||
1811 | @end deffn | |
1812 | ||
1813 | ||
1814 | @node Conditionals, Assignments, Procedures, Primitive expression types | |
1815 | @subsection Conditionals | |
1816 | ||
1817 | ||
1818 | ||
1819 | @deffn {syntax} if @r{<test>} @r{<consequent>} @r{<alternate>} | |
1820 | @deffnx {syntax} if @r{<test>} @r{<consequent>} | |
1821 | @c \/ if hyper = italic | |
1822 | ||
1823 | @emph{Syntax:} | |
1824 | @r{<Test>}, @r{<consequent>}, and @r{<alternate>} may be arbitrary | |
1825 | expressions. | |
1826 | ||
1827 | @emph{Semantics:} | |
1828 | An @samp{if} expression is evaluated as follows: first, | |
1829 | @r{<test>} is evaluated. If it yields a true value (see | |
1830 | @cindex @w{true} | |
1831 | section @pxref{Booleans}), then @r{<consequent>} is evaluated and | |
1832 | its value(s) is(are) returned. Otherwise @r{<alternate>} is evaluated and its | |
1833 | value(s) is(are) returned. If @r{<test>} yields a false value and no | |
1834 | @r{<alternate>} is specified, then the result of the expression is | |
1835 | unspecified. | |
1836 | ||
1837 | ||
1838 | @format | |
1839 | @t{(if (> 3 2) 'yes 'no) ==> yes | |
1840 | (if (> 2 3) 'yes 'no) ==> no | |
1841 | (if (> 3 2) | |
1842 | (- 3 2) | |
1843 | (+ 3 2)) ==> 1 | |
1844 | } | |
1845 | @end format | |
1846 | ||
1847 | ||
1848 | @end deffn | |
1849 | ||
1850 | ||
1851 | @node Assignments, , Conditionals, Primitive expression types | |
1852 | @subsection Assignments | |
1853 | ||
1854 | ||
1855 | ||
1856 | ||
1857 | @deffn {syntax} set! @r{<variable>} @r{<expression>} | |
1858 | ||
1859 | @r{<Expression>} is evaluated, and the resulting value is stored in | |
1860 | the location to which @r{<variable>} is bound. @r{<Variable>} must | |
1861 | be bound either in some region enclosing the @samp{set!} expression | |
1862 | @cindex @w{region} | |
1863 | or at top level. The result of the @samp{set!} expression is | |
1864 | unspecified. | |
1865 | ||
1866 | ||
1867 | @format | |
1868 | @t{(define x 2) | |
1869 | (+ x 1) ==> 3 | |
1870 | (set! x 4) ==> @emph{unspecified} | |
1871 | (+ x 1) ==> 5 | |
1872 | } | |
1873 | @end format | |
1874 | ||
1875 | ||
1876 | @end deffn | |
1877 | ||
1878 | ||
1879 | @node Derived expression types, Macros, Primitive expression types, Expressions | |
1880 | @section Derived expression types | |
1881 | ||
1882 | @menu | |
1883 | * Conditional:: | |
1884 | * Binding constructs:: | |
1885 | * Sequencing:: | |
1886 | * Iteration:: | |
1887 | * Delayed evaluation:: | |
1888 | * Quasiquotation:: | |
1889 | @end menu | |
1890 | ||
1891 | ||
1892 | ||
1893 | The constructs in this section are hygienic, as discussed in | |
1894 | section @ref{Macros}. | |
1895 | For reference purposes, section @ref{Derived expression type} gives macro definitions | |
1896 | that will convert most of the constructs described in this section | |
1897 | into the primitive constructs described in the previous section. | |
1898 | ||
1899 | @ignore todo | |
1900 | Mention that no definition of backquote is provided? | |
1901 | @end ignore | |
1902 | ||
1903 | ||
1904 | @node Conditional, Binding constructs, Derived expression types, Derived expression types | |
1905 | @subsection Conditionals | |
1906 | ||
1907 | ||
1908 | ||
1909 | @deffn {library syntax} cond <clause1> <clause2> @dots{}, | |
1910 | ||
1911 | @emph{Syntax:} | |
1912 | Each @r{<clause>} should be of the form | |
1913 | ||
1914 | @format | |
1915 | @t{(@r{<test>} @r{<expression1>} @dots{},) | |
1916 | } | |
1917 | @end format | |
1918 | ||
1919 | where @r{<test>} is any expression. Alternatively, a @r{<clause>} may be | |
1920 | of the form | |
1921 | ||
1922 | @format | |
1923 | @t{(@r{<test>} => @r{<expression>}) | |
1924 | } | |
1925 | @end format | |
1926 | ||
1927 | The last @r{<clause>} may be | |
1928 | an ``else clause,'' which has the form | |
1929 | ||
1930 | @format | |
1931 | @t{(else @r{<expression1>} @r{<expression2>} @dots{},)@r{.} | |
1932 | } | |
1933 | @end format | |
1934 | ||
1935 | ||
1936 | @cindex @w{else} | |
1937 | ||
1938 | @cindex @w{=>} | |
1939 | ||
1940 | @emph{Semantics:} | |
1941 | A @samp{cond} expression is evaluated by evaluating the @r{<test>} | |
1942 | expressions of successive @r{<clause>}s in order until one of them | |
1943 | evaluates to a true value (see | |
1944 | @cindex @w{true} | |
1945 | section @pxref{Booleans}). When a @r{<test>} evaluates to a true | |
1946 | value, then the remaining @r{<expression>}s in its @r{<clause>} are | |
1947 | evaluated in order, and the result(s) of the last @r{<expression>} in the | |
1948 | @r{<clause>} is(are) returned as the result(s) of the entire @samp{cond} | |
1949 | expression. If the selected @r{<clause>} contains only the | |
1950 | @r{<test>} and no @r{<expression>}s, then the value of the | |
1951 | @r{<test>} is returned as the result. If the selected @r{<clause>} uses the | |
1952 | @code{=>} alternate form, then the @r{<expression>} is evaluated. | |
1953 | @vindex @w{=>} | |
1954 | Its value must be a procedure that accepts one argument; this procedure is then | |
1955 | called on the value of the @r{<test>} and the value(s) returned by this | |
1956 | procedure is(are) returned by the @samp{cond} expression. | |
1957 | If all @r{<test>}s evaluate | |
1958 | to false values, and there is no else clause, then the result of | |
1959 | the conditional expression is unspecified; if there is an else | |
1960 | clause, then its @r{<expression>}s are evaluated, and the value(s) of | |
1961 | the last one is(are) returned. | |
1962 | ||
1963 | ||
1964 | @format | |
1965 | @t{(cond ((> 3 2) 'greater) | |
1966 | ((< 3 2) 'less)) ==> greater | |
1967 | ||
1968 | (cond ((> 3 3) 'greater) | |
1969 | ((< 3 3) 'less) | |
1970 | (else 'equal)) ==> equal | |
1971 | ||
1972 | (cond ((assv 'b '((a 1) (b 2))) => cadr) | |
1973 | (else #f)) ==> 2 | |
1974 | } | |
1975 | @end format | |
1976 | ||
1977 | ||
1978 | ||
1979 | @end deffn | |
1980 | ||
1981 | ||
1982 | ||
1983 | @deffn {library syntax} case @r{<key>} <clause1> <clause2> @dots{}, | |
1984 | ||
1985 | @emph{Syntax:} | |
1986 | @r{<Key>} may be any expression. Each @r{<clause>} should have | |
1987 | the form | |
1988 | ||
1989 | @format | |
1990 | @t{((@r{<datum1>} @dots{},) @r{<expression1>} @r{<expression2>} @dots{},)@r{,} | |
1991 | } | |
1992 | @end format | |
1993 | ||
1994 | where each @r{<datum>} is an external representation of some object. | |
1995 | All the @r{<datum>}s must be distinct. | |
1996 | The last @r{<clause>} may be an ``else clause,'' which has the form | |
1997 | ||
1998 | @format | |
1999 | @t{(else @r{<expression1>} @r{<expression2>} @dots{},)@r{.} | |
2000 | } | |
2001 | @end format | |
2002 | ||
2003 | ||
2004 | @vindex else | |
2005 | ||
2006 | @emph{Semantics:} | |
2007 | A @samp{case} expression is evaluated as follows. @r{<Key>} is | |
2008 | evaluated and its result is compared against each @r{<datum>}. If the | |
2009 | result of evaluating @r{<key>} is equivalent (in the sense of | |
2010 | @samp{eqv?}; see section @pxref{Equivalence predicates}) to a @r{<datum>}, then the | |
2011 | expressions in the corresponding @r{<clause>} are evaluated from left | |
2012 | to right and the result(s) of the last expression in the @r{<clause>} is(are) | |
2013 | returned as the result(s) of the @samp{case} expression. If the result of | |
2014 | evaluating @r{<key>} is different from every @r{<datum>}, then if | |
2015 | there is an else clause its expressions are evaluated and the | |
2016 | result(s) of the last is(are) the result(s) of the @samp{case} expression; | |
2017 | otherwise the result of the @samp{case} expression is unspecified. | |
2018 | ||
2019 | ||
2020 | @format | |
2021 | @t{(case (* 2 3) | |
2022 | ((2 3 5 7) 'prime) | |
2023 | ((1 4 6 8 9) 'composite)) ==> composite | |
2024 | (case (car '(c d)) | |
2025 | ((a) 'a) | |
2026 | ((b) 'b)) ==> @emph{unspecified} | |
2027 | (case (car '(c d)) | |
2028 | ((a e i o u) 'vowel) | |
2029 | ((w y) 'semivowel) | |
2030 | (else 'consonant)) ==> consonant | |
2031 | } | |
2032 | @end format | |
2033 | ||
2034 | ||
2035 | @end deffn | |
2036 | ||
2037 | ||
2038 | ||
2039 | @deffn {library syntax} and <test1> @dots{}, | |
2040 | ||
2041 | The @r{<test>} expressions are evaluated from left to right, and the | |
2042 | value of the first expression that evaluates to a false value (see | |
2043 | section @pxref{Booleans}) is returned. Any remaining expressions | |
2044 | are not evaluated. If all the expressions evaluate to true values, the | |
2045 | value of the last expression is returned. If there are no expressions | |
2046 | then @t{#t} is returned. | |
2047 | ||
2048 | ||
2049 | @format | |
2050 | @t{(and (= 2 2) (> 2 1)) ==> #t | |
2051 | (and (= 2 2) (< 2 1)) ==> #f | |
2052 | (and 1 2 'c '(f g)) ==> (f g) | |
2053 | (and) ==> #t | |
2054 | } | |
2055 | @end format | |
2056 | ||
2057 | ||
2058 | @end deffn | |
2059 | ||
2060 | ||
2061 | ||
2062 | @deffn {library syntax} or <test1> @dots{}, | |
2063 | ||
2064 | The @r{<test>} expressions are evaluated from left to right, and the value of the | |
2065 | first expression that evaluates to a true value (see | |
2066 | section @pxref{Booleans}) is returned. Any remaining expressions | |
2067 | are not evaluated. If all expressions evaluate to false values, the | |
2068 | value of the last expression is returned. If there are no | |
2069 | expressions then @t{#f} is returned. | |
2070 | ||
2071 | ||
2072 | @format | |
2073 | @t{(or (= 2 2) (> 2 1)) ==> #t | |
2074 | (or (= 2 2) (< 2 1)) ==> #t | |
2075 | (or #f #f #f) ==> #f | |
2076 | (or (memq 'b '(a b c)) | |
2077 | (/ 3 0)) ==> (b c) | |
2078 | } | |
2079 | @end format | |
2080 | ||
2081 | ||
2082 | @end deffn | |
2083 | ||
2084 | ||
2085 | @node Binding constructs, Sequencing, Conditional, Derived expression types | |
2086 | @subsection Binding constructs | |
2087 | ||
2088 | ||
2089 | The three binding constructs @samp{let}, @samp{let*}, and @samp{letrec} | |
2090 | give Scheme a block structure, like Algol 60. The syntax of the three | |
2091 | constructs is identical, but they differ in the regions they establish | |
2092 | @cindex @w{region} | |
2093 | for their variable bindings. In a @samp{let} expression, the initial | |
2094 | values are computed before any of the variables become bound; in a | |
2095 | @samp{let*} expression, the bindings and evaluations are performed | |
2096 | sequentially; while in a @samp{letrec} expression, all the bindings are in | |
2097 | effect while their initial values are being computed, thus allowing | |
2098 | mutually recursive definitions. | |
2099 | ||
2100 | ||
2101 | @deffn {library syntax} let @r{<bindings>} @r{<body>} | |
2102 | ||
2103 | @emph{Syntax:} | |
2104 | @r{<Bindings>} should have the form | |
2105 | ||
2106 | @format | |
2107 | @t{((@r{<variable1>} @r{<init1>}) @dots{},)@r{,} | |
2108 | } | |
2109 | @end format | |
2110 | ||
2111 | where each @r{<init>} is an expression, and @r{<body>} should be a | |
2112 | sequence of one or more expressions. It is | |
2113 | an error for a @r{<variable>} to appear more than once in the list of variables | |
2114 | being bound. | |
2115 | ||
2116 | @emph{Semantics:} | |
2117 | The @r{<init>}s are evaluated in the current environment (in some | |
2118 | unspecified order), the @r{<variable>}s are bound to fresh locations | |
2119 | holding the results, the @r{<body>} is evaluated in the extended | |
2120 | environment, and the value(s) of the last expression of @r{<body>} | |
2121 | is(are) returned. Each binding of a @r{<variable>} has @r{<body>} as its | |
2122 | region. | |
2123 | @cindex @w{region} | |
2124 | ||
2125 | ||
2126 | @format | |
2127 | @t{(let ((x 2) (y 3)) | |
2128 | (* x y)) ==> 6 | |
2129 | ||
2130 | (let ((x 2) (y 3)) | |
2131 | (let ((x 7) | |
2132 | (z (+ x y))) | |
2133 | (* z x))) ==> 35 | |
2134 | } | |
2135 | @end format | |
2136 | ||
2137 | ||
2138 | See also named @samp{let}, section @ref{Iteration}. | |
2139 | ||
2140 | @end deffn | |
2141 | ||
2142 | ||
2143 | ||
2144 | @deffn {library syntax} let* @r{<bindings>} @r{<body>} | |
2145 | ||
2146 | ||
2147 | @emph{Syntax:} | |
2148 | @r{<Bindings>} should have the form | |
2149 | ||
2150 | @format | |
2151 | @t{((@r{<variable1>} @r{<init1>}) @dots{},)@r{,} | |
2152 | } | |
2153 | @end format | |
2154 | ||
2155 | and @r{<body>} should be a sequence of | |
2156 | one or more expressions. | |
2157 | ||
2158 | @emph{Semantics:} | |
2159 | @samp{Let*} is similar to @samp{let}, but the bindings are performed | |
2160 | sequentially from left to right, and the region of a binding indicated | |
2161 | @cindex @w{region} | |
2162 | by @samp{(@r{<variable>} @r{<init>})} is that part of the @samp{let*} | |
2163 | expression to the right of the binding. Thus the second binding is done | |
2164 | in an environment in which the first binding is visible, and so on. | |
2165 | ||
2166 | ||
2167 | @format | |
2168 | @t{(let ((x 2) (y 3)) | |
2169 | (let* ((x 7) | |
2170 | (z (+ x y))) | |
2171 | (* z x))) ==> 70 | |
2172 | } | |
2173 | @end format | |
2174 | ||
2175 | ||
2176 | @end deffn | |
2177 | ||
2178 | ||
2179 | ||
2180 | @deffn {library syntax} letrec @r{<bindings>} @r{<body>} | |
2181 | ||
2182 | @emph{Syntax:} | |
2183 | @r{<Bindings>} should have the form | |
2184 | ||
2185 | @format | |
2186 | @t{((@r{<variable1>} @r{<init1>}) @dots{},)@r{,} | |
2187 | } | |
2188 | @end format | |
2189 | ||
2190 | and @r{<body>} should be a sequence of | |
2191 | one or more expressions. It is an error for a @r{<variable>} to appear more | |
2192 | than once in the list of variables being bound. | |
2193 | ||
2194 | @emph{Semantics:} | |
2195 | The @r{<variable>}s are bound to fresh locations holding undefined | |
2196 | values, the @r{<init>}s are evaluated in the resulting environment (in | |
2197 | some unspecified order), each @r{<variable>} is assigned to the result | |
2198 | of the corresponding @r{<init>}, the @r{<body>} is evaluated in the | |
2199 | resulting environment, and the value(s) of the last expression in | |
2200 | @r{<body>} is(are) returned. Each binding of a @r{<variable>} has the | |
2201 | entire @samp{letrec} expression as its region, making it possible to | |
2202 | @cindex @w{region} | |
2203 | define mutually recursive procedures. | |
2204 | ||
2205 | ||
2206 | @format | |
2207 | @t{(letrec ((even? | |
2208 | (lambda (n) | |
2209 | (if (zero? n) | |
2210 | #t | |
2211 | (odd? (- n 1))))) | |
2212 | (odd? | |
2213 | (lambda (n) | |
2214 | (if (zero? n) | |
2215 | #f | |
2216 | (even? (- n 1)))))) | |
2217 | (even? 88)) | |
2218 | ==> #t | |
2219 | } | |
2220 | @end format | |
2221 | ||
2222 | ||
2223 | One restriction on @samp{letrec} is very important: it must be possible | |
2224 | to evaluate each @r{<init>} without assigning or referring to the value of any | |
2225 | @r{<variable>}. If this restriction is violated, then it is an error. The | |
2226 | restriction is necessary because Scheme passes arguments by value rather than by | |
2227 | name. In the most common uses of @samp{letrec}, all the @r{<init>}s are | |
2228 | lambda expressions and the restriction is satisfied automatically. | |
2229 | ||
2230 | @c \todo{use or uses? --- Jinx.} | |
2231 | ||
2232 | @end deffn | |
2233 | ||
2234 | ||
2235 | @node Sequencing, Iteration, Binding constructs, Derived expression types | |
2236 | @subsection Sequencing | |
2237 | ||
2238 | ||
2239 | ||
2240 | @deffn {library syntax} begin <expression1> <expression2> @dots{}, | |
2241 | ||
2242 | The @r{<expression>}s are evaluated sequentially from left to right, | |
2243 | and the value(s) of the last @r{<expression>} is(are) returned. This | |
2244 | expression type is used to sequence side effects such as input and | |
2245 | output. | |
2246 | ||
2247 | ||
2248 | @format | |
2249 | @t{(define x 0) | |
2250 | ||
2251 | (begin (set! x 5) | |
2252 | (+ x 1)) ==> 6 | |
2253 | ||
2254 | (begin (display "4 plus 1 equals ") | |
2255 | (display (+ 4 1))) ==> @emph{unspecified} | |
2256 | @emph{and prints} 4 plus 1 equals 5 | |
2257 | } | |
2258 | @end format | |
2259 | ||
2260 | ||
2261 | @end deffn | |
2262 | ||
2263 | ||
2264 | @node Iteration, Delayed evaluation, Sequencing, Derived expression types | |
2265 | @subsection Iteration | |
2266 | ||
2267 | @c \unsection | |
2268 | ||
2269 | ||
2270 | @noindent | |
2271 | ||
2272 | @deffn {library syntax} do ((@r{<variable1>} @r{<init1>} @r{<step1>}) @dots{}) (@r{<test>} @r{<expression>} @dots{}) @r{<command>} @dots{} | |
2273 | @cindex @w{do} | |
2274 | ||
2275 | @samp{Do} is an iteration construct. It specifies a set of variables to | |
2276 | be bound, how they are to be initialized at the start, and how they are | |
2277 | to be updated on each iteration. When a termination condition is met, | |
2278 | the loop exits after evaluating the @r{<expression>}s. | |
2279 | ||
2280 | @samp{Do} expressions are evaluated as follows: | |
2281 | The @r{<init>} expressions are evaluated (in some unspecified order), | |
2282 | the @r{<variable>}s are bound to fresh locations, the results of the | |
2283 | @r{<init>} expressions are stored in the bindings of the | |
2284 | @r{<variable>}s, and then the iteration phase begins. | |
2285 | ||
2286 | Each iteration begins by evaluating @r{<test>}; if the result is | |
2287 | false (see section @pxref{Booleans}), then the @r{<command>} | |
2288 | expressions are evaluated in order for effect, the @r{<step>} | |
2289 | expressions are evaluated in some unspecified order, the | |
2290 | @r{<variable>}s are bound to fresh locations, the results of the | |
2291 | @r{<step>}s are stored in the bindings of the | |
2292 | @r{<variable>}s, and the next iteration begins. | |
2293 | ||
2294 | If @r{<test>} evaluates to a true value, then the | |
2295 | @r{<expression>}s are evaluated from left to right and the value(s) of | |
2296 | the last @r{<expression>} is(are) returned. If no @r{<expression>}s | |
2297 | are present, then the value of the @samp{do} expression is unspecified. | |
2298 | ||
2299 | The region of the binding of a @r{<variable>} | |
2300 | @cindex @w{region} | |
2301 | consists of the entire @samp{do} expression except for the @r{<init>}s. | |
2302 | It is an error for a @r{<variable>} to appear more than once in the | |
2303 | list of @samp{do} variables. | |
2304 | ||
2305 | A @r{<step>} may be omitted, in which case the effect is the | |
2306 | same as if @samp{(@r{<variable>} @r{<init>} @r{<variable>})} had | |
2307 | been written instead of @samp{(@r{<variable>} @r{<init>})}. | |
2308 | ||
2309 | ||
2310 | @format | |
2311 | @t{(do ((vec (make-vector 5)) | |
2312 | (i 0 (+ i 1))) | |
2313 | ((= i 5) vec) | |
2314 | (vector-set! vec i i)) ==> #(0 1 2 3 4) | |
2315 | ||
2316 | (let ((x '(1 3 5 7 9))) | |
2317 | (do ((x x (cdr x)) | |
2318 | (sum 0 (+ sum (car x)))) | |
2319 | ((null? x) sum))) ==> 25 | |
2320 | } | |
2321 | @end format | |
2322 | ||
2323 | ||
2324 | @c \end{entry} | |
2325 | @end deffn | |
2326 | ||
2327 | ||
2328 | @deffn {library syntax} let @r{<variable>} @r{<bindings>} @r{<body>} | |
2329 | ||
2330 | ||
2331 | ``Named @samp{let}'' is a variant on the syntax of @code{let} which provides | |
2332 | @vindex @w{let} | |
2333 | a more general looping construct than @samp{do} and may also be used to express | |
2334 | recursions. | |
2335 | It has the same syntax and semantics as ordinary @samp{let} | |
2336 | except that @r{<variable>} is bound within @r{<body>} to a procedure | |
2337 | whose formal arguments are the bound variables and whose body is | |
2338 | @r{<body>}. Thus the execution of @r{<body>} may be repeated by | |
2339 | invoking the procedure named by @r{<variable>}. | |
2340 | ||
2341 | @c | <-- right margin | |
2342 | ||
2343 | @format | |
2344 | @t{(let loop ((numbers '(3 -2 1 6 -5)) | |
2345 | (nonneg '()) | |
2346 | (neg '())) | |
2347 | (cond ((null? numbers) (list nonneg neg)) | |
2348 | ((>= (car numbers) 0) | |
2349 | (loop (cdr numbers) | |
2350 | (cons (car numbers) nonneg) | |
2351 | neg)) | |
2352 | ((< (car numbers) 0) | |
2353 | (loop (cdr numbers) | |
2354 | nonneg | |
2355 | (cons (car numbers) neg))))) | |
2356 | ==> ((6 1 3) (-5 -2)) | |
2357 | } | |
2358 | @end format | |
2359 | ||
2360 | ||
2361 | @end deffn | |
2362 | ||
2363 | ||
2364 | @node Delayed evaluation, Quasiquotation, Iteration, Derived expression types | |
2365 | @subsection Delayed evaluation | |
2366 | ||
2367 | ||
2368 | ||
2369 | @deffn {library syntax} delay @r{<expression>} | |
2370 | ||
2371 | @ignore todo | |
2372 | Fix. | |
2373 | @end ignore | |
2374 | ||
2375 | ||
2376 | The @samp{delay} construct is used together with the procedure @code{force} to | |
2377 | @vindex @w{force} | |
2378 | implement @dfn{lazy evaluation} or @dfn{call by need}. | |
2379 | @cindex @w{call by need} | |
2380 | @cindex @w{lazy evaluation} | |
2381 | @t{(delay @r{<expression>})} returns an object called a | |
2382 | @dfn{promise} which at some point in the future may be asked (by | |
2383 | @cindex @w{promise} | |
2384 | the @samp{force} procedure) | |
2385 | @ignore todo | |
2386 | Bartley's white lie; OK? | |
2387 | @end ignore | |
2388 | to evaluate | |
2389 | @r{<expression>}, and deliver the resulting value. | |
2390 | The effect of @r{<expression>} returning multiple values | |
2391 | is unspecified. | |
2392 | ||
2393 | See the description of @samp{force} (section @pxref{Control features}) for a | |
2394 | more complete description of @samp{delay}. | |
2395 | ||
2396 | @end deffn | |
2397 | ||
2398 | ||
2399 | @node Quasiquotation, , Delayed evaluation, Derived expression types | |
2400 | @subsection Quasiquotation | |
2401 | ||
2402 | ||
2403 | ||
2404 | ||
2405 | @deffn {syntax} quasiquote @r{<qq template>} | |
2406 | ||
2407 | @deffnx {syntax} @t{`}@r{<qq template>} | |
2408 | ||
2409 | ||
2410 | ``Backquote'' or ``quasiquote'' expressions are useful | |
2411 | @cindex @w{backquote} | |
2412 | for constructing a list or vector structure when most but not all of the | |
2413 | desired structure is known in advance. If no | |
2414 | commas appear within the @r{<qq template>}, the result of | |
2415 | @cindex @w{comma} | |
2416 | evaluating | |
2417 | @t{`}@r{<qq template>} is equivalent to the result of evaluating | |
2418 | @t{'}@r{<qq template>}. If a comma appears within the | |
2419 | @cindex @w{,} | |
2420 | @r{<qq template>}, however, the expression following the comma is | |
2421 | evaluated (``unquoted'') and its result is inserted into the structure | |
2422 | instead of the comma and the expression. If a comma appears followed | |
2423 | immediately by an at-sign (@@), then the following | |
2424 | @cindex @w{,@@} | |
2425 | expression must evaluate to a list; the opening and closing parentheses | |
2426 | of the list are then ``stripped away'' and the elements of the list are | |
2427 | inserted in place of the comma at-sign expression sequence. A comma | |
2428 | at-sign should only appear within a list or vector @r{<qq template>}. | |
2429 | ||
2430 | @c struck: "(in the sense of {\cf equal?})" after "equivalent" | |
2431 | ||
2432 | ||
2433 | @format | |
2434 | @t{`(list ,(+ 1 2) 4) ==> (list 3 4) | |
2435 | (let ((name 'a)) `(list ,name ',name)) | |
2436 | ==> (list a (quote a)) | |
2437 | `(a ,(+ 1 2) ,@@(map abs '(4 -5 6)) b) | |
2438 | ==> (a 3 4 5 6 b) | |
2439 | `((@samp{foo} ,(- 10 3)) ,@@(cdr '(c)) . ,(car '(cons))) | |
2440 | ==> ((foo 7) . cons) | |
2441 | `#(10 5 ,(sqrt 4) ,@@(map sqrt '(16 9)) 8) | |
2442 | ==> #(10 5 2 4 3 8) | |
2443 | } | |
2444 | @end format | |
2445 | ||
2446 | ||
2447 | Quasiquote forms may be nested. Substitutions are made only for | |
2448 | unquoted components appearing at the same nesting level | |
2449 | as the outermost backquote. The nesting level increases by one inside | |
2450 | each successive quasiquotation, and decreases by one inside each | |
2451 | unquotation. | |
2452 | ||
2453 | ||
2454 | @format | |
2455 | @t{`(a `(b ,(+ 1 2) ,(foo ,(+ 1 3) d) e) f) | |
2456 | ==> (a `(b ,(+ 1 2) ,(foo 4 d) e) f) | |
2457 | (let ((name1 'x) | |
2458 | (name2 'y)) | |
2459 | `(a `(b ,,name1 ,',name2 d) e)) | |
2460 | ==> (a `(b ,x ,'y d) e) | |
2461 | } | |
2462 | @end format | |
2463 | ||
2464 | ||
2465 | The two notations | |
2466 | @t{`}@r{<qq template>} and @t{(quasiquote @r{<qq template>})} | |
2467 | are identical in all respects. | |
2468 | @samp{,@r{<expression>}} is identical to @samp{(unquote @r{<expression>})}, | |
2469 | and | |
2470 | @samp{,@@@r{<expression>}} is identical to @samp{(unquote-splicing @r{<expression>})}. | |
2471 | The external syntax generated by @code{write} for two-element lists whose | |
2472 | @vindex @w{write} | |
2473 | car is one of these symbols may vary between implementations. | |
2474 | ||
2475 | @cindex @w{`} | |
2476 | ||
2477 | ||
2478 | @format | |
2479 | @t{(quasiquote (list (unquote (+ 1 2)) 4)) | |
2480 | ==> (list 3 4) | |
2481 | '(quasiquote (list (unquote (+ 1 2)) 4)) | |
2482 | ==> `(list ,(+ 1 2) 4) | |
2483 | @emph{}i.e., (quasiquote (list (unquote (+ 1 2)) 4)) | |
2484 | } | |
2485 | @end format | |
2486 | ||
2487 | ||
2488 | Unpredictable behavior can result if any of the symbols | |
2489 | @code{quasiquote}, @code{unquote}, or @code{unquote-splicing} appear in | |
2490 | @vindex @w{unquote-splicing} | |
2491 | @vindex @w{unquote} | |
2492 | @vindex @w{quasiquote} | |
2493 | positions within a @r{<qq template>} otherwise than as described above. | |
2494 | ||
2495 | @end deffn | |
2496 | ||
2497 | @node Macros, , Derived expression types, Expressions | |
2498 | @section Macros | |
2499 | ||
2500 | @menu | |
2501 | * Binding constructs for syntactic keywords:: | |
2502 | * Pattern language:: | |
2503 | @end menu | |
2504 | ||
2505 | ||
2506 | ||
2507 | Scheme programs can define and use new derived expression types, | |
2508 | called @emph{macros}. | |
2509 | @cindex @w{macro} | |
2510 | Program-defined expression types have the syntax | |
2511 | ||
2512 | @example | |
2513 | ||
2514 | (@r{<keyword>} @r{<datum>} ...) | |
2515 | ||
2516 | @end example | |
2517 | ||
2518 | where @r{<keyword>} is an identifier that uniquely determines the | |
2519 | expression type. This identifier is called the @emph{syntactic | |
2520 | keyword}, or simply @emph{keyword}, of the macro. The | |
2521 | @cindex @w{macro keyword} | |
2522 | @cindex @w{keyword} | |
2523 | @cindex @w{syntactic keyword} | |
2524 | number of the @r{<datum>}s, and their syntax, depends on the | |
2525 | expression type. | |
2526 | ||
2527 | Each instance of a macro is called a @emph{use} | |
2528 | @cindex @w{macro use} | |
2529 | of the macro. | |
2530 | The set of rules that specifies | |
2531 | how a use of a macro is transcribed into a more primitive expression | |
2532 | is called the @emph{transformer} | |
2533 | @cindex @w{macro transformer} | |
2534 | of the macro. | |
2535 | ||
2536 | The macro definition facility consists of two parts: | |
2537 | ||
2538 | ||
2539 | ||
2540 | @itemize @bullet | |
2541 | ||
2542 | @item | |
2543 | A set of expressions used to establish that certain identifiers | |
2544 | are macro keywords, associate them with macro transformers, and control | |
2545 | the scope within which a macro is defined, and | |
2546 | ||
2547 | @item | |
2548 | a pattern language for specifying macro transformers. | |
2549 | ||
2550 | @end itemize | |
2551 | ||
2552 | ||
2553 | The syntactic keyword of a macro may shadow variable bindings, and local | |
2554 | variable bindings may shadow keyword bindings. All macros | |
2555 | @cindex @w{keyword} | |
2556 | defined using the pattern language are ``hygienic'' and ``referentially | |
2557 | transparent'' and thus preserve Scheme's lexical scoping [Kohlbecker86], [ | |
2558 | hygienic], [Bawden88], [macrosthatwork], [syntacticabstraction]: | |
2559 | ||
2560 | @cindex @w{hygienic} | |
2561 | ||
2562 | @cindex @w{referentially transparent} | |
2563 | ||
2564 | ||
2565 | ||
2566 | ||
2567 | @itemize @bullet | |
2568 | ||
2569 | ||
2570 | @item | |
2571 | If a macro transformer inserts a binding for an identifier | |
2572 | (variable or keyword), the identifier will in effect be renamed | |
2573 | throughout its scope to avoid conflicts with other identifiers. | |
2574 | Note that a @code{define} at top level may or may not introduce a binding; | |
2575 | see section @ref{Definitions}. | |
2576 | ||
2577 | @item | |
2578 | If a macro transformer inserts a free reference to an | |
2579 | identifier, the reference refers to the binding that was visible | |
2580 | where the transformer was specified, regardless of any local | |
2581 | bindings that may surround the use of the macro. | |
2582 | ||
2583 | ||
2584 | @end itemize | |
2585 | ||
2586 | @vindex @w{define} | |
2587 | ||
2588 | @c The low-level facility permits non-hygienic macros to be written, | |
2589 | @c and may be used to implement the high-level pattern language. | |
2590 | ||
2591 | @c The fourth section describes some features that would make the | |
2592 | @c low-level macro facility easier to use directly. | |
2593 | ||
2594 | @node Binding constructs for syntactic keywords, Pattern language, Macros, Macros | |
2595 | @subsection Binding constructs for syntactic keywords | |
2596 | ||
2597 | ||
2598 | ||
2599 | @samp{Let-syntax} and @samp{letrec-syntax} are | |
2600 | analogous to @samp{let} and @samp{letrec}, but they bind | |
2601 | syntactic keywords to macro transformers instead of binding variables | |
2602 | to locations that contain values. Syntactic keywords may also be | |
2603 | bound at top level; see section @ref{Syntax definitions}. | |
2604 | ||
2605 | ||
2606 | @deffn {syntax} let-syntax @r{<bindings>} @r{<body>} | |
2607 | ||
2608 | @emph{Syntax:} | |
2609 | @r{<Bindings>} should have the form | |
2610 | ||
2611 | @format | |
2612 | @t{((@r{<keyword>} @r{<transformer spec>}) @dots{},) | |
2613 | } | |
2614 | @end format | |
2615 | ||
2616 | Each @r{<keyword>} is an identifier, | |
2617 | each @r{<transformer spec>} is an instance of @samp{syntax-rules}, and | |
2618 | @r{<body>} should be a sequence of one or more expressions. It is an error | |
2619 | for a @r{<keyword>} to appear more than once in the list of keywords | |
2620 | being bound. | |
2621 | ||
2622 | @emph{Semantics:} | |
2623 | The @r{<body>} is expanded in the syntactic environment | |
2624 | obtained by extending the syntactic environment of the | |
2625 | @samp{let-syntax} expression with macros whose keywords are | |
2626 | the @r{<keyword>}s, bound to the specified transformers. | |
2627 | Each binding of a @r{<keyword>} has @r{<body>} as its region. | |
2628 | ||
2629 | ||
2630 | @format | |
2631 | @t{(let-syntax ((when (syntax-rules () | |
2632 | ((when test stmt1 stmt2 ...) | |
2633 | (if test | |
2634 | (begin stmt1 | |
2635 | stmt2 ...)))))) | |
2636 | (let ((if #t)) | |
2637 | (when if (set! if 'now)) | |
2638 | if)) ==> now | |
2639 | ||
2640 | (let ((x 'outer)) | |
2641 | (let-syntax ((m (syntax-rules () ((m) x)))) | |
2642 | (let ((x 'inner)) | |
2643 | (m)))) ==> outer | |
2644 | } | |
2645 | @end format | |
2646 | ||
2647 | ||
2648 | @end deffn | |
2649 | ||
2650 | ||
2651 | @deffn {syntax} letrec-syntax @r{<bindings>} @r{<body>} | |
2652 | ||
2653 | @emph{Syntax:} | |
2654 | Same as for @samp{let-syntax}. | |
2655 | ||
2656 | @emph{Semantics:} | |
2657 | The @r{<body>} is expanded in the syntactic environment obtained by | |
2658 | extending the syntactic environment of the @samp{letrec-syntax} | |
2659 | expression with macros whose keywords are the | |
2660 | @r{<keyword>}s, bound to the specified transformers. | |
2661 | Each binding of a @r{<keyword>} has the @r{<bindings>} | |
2662 | as well as the @r{<body>} within its region, | |
2663 | so the transformers can | |
2664 | transcribe expressions into uses of the macros | |
2665 | introduced by the @samp{letrec-syntax} expression. | |
2666 | ||
2667 | ||
2668 | @format | |
2669 | @t{(letrec-syntax | |
2670 | ((my-or (syntax-rules () | |
2671 | ((my-or) #f) | |
2672 | ((my-or e) e) | |
2673 | ((my-or e1 e2 ...) | |
2674 | (let ((temp e1)) | |
2675 | (if temp | |
2676 | temp | |
2677 | (my-or e2 ...))))))) | |
2678 | (let ((x #f) | |
2679 | (y 7) | |
2680 | (temp 8) | |
2681 | (let odd?) | |
2682 | (if even?)) | |
2683 | (my-or x | |
2684 | (let temp) | |
2685 | (if y) | |
2686 | y))) ==> 7 | |
2687 | } | |
2688 | @end format | |
2689 | ||
2690 | ||
2691 | @end deffn | |
2692 | ||
2693 | @node Pattern language, , Binding constructs for syntactic keywords, Macros | |
2694 | @subsection Pattern language | |
2695 | ||
2696 | ||
2697 | ||
2698 | A @r{<transformer spec>} has the following form: | |
2699 | ||
2700 | ||
2701 | @deffn {} syntax-rules @r{<literals>} @r{<syntax rule>} @dots{}, | |
2702 | ||
2703 | @emph{Syntax:} | |
2704 | @r{<Literals>} is a list of identifiers and each @r{<syntax rule>} | |
2705 | should be of the form | |
2706 | ||
2707 | @format | |
2708 | @t{(@r{<pattern>} @r{<template>}) | |
2709 | } | |
2710 | @end format | |
2711 | ||
2712 | The @r{<pattern>} in a @r{<syntax rule>} is a list @r{<pattern>} | |
2713 | that begins with the keyword for the macro. | |
2714 | ||
2715 | A @r{<pattern>} is either an identifier, a constant, or one of the | |
2716 | following | |
2717 | ||
2718 | @format | |
2719 | @t{(@r{<pattern>} @dots{}) | |
2720 | (@r{<pattern>} @r{<pattern>} @dots{} . @r{<pattern>}) | |
2721 | (@r{<pattern>} @dots{} @r{<pattern>} @r{<ellipsis>}) | |
2722 | #(@r{<pattern>} @dots{}) | |
2723 | #(@r{<pattern>} @dots{} @r{<pattern>} @r{<ellipsis>}) | |
2724 | } | |
2725 | @end format | |
2726 | ||
2727 | and a template is either an identifier, a constant, or one of the following | |
2728 | ||
2729 | @format | |
2730 | @t{(@r{<element>} @dots{}) | |
2731 | (@r{<element>} @r{<element>} @dots{} . @r{<template>}) | |
2732 | #(@r{<element>} @dots{}) | |
2733 | } | |
2734 | @end format | |
2735 | ||
2736 | where an @r{<element>} is a @r{<template>} optionally | |
2737 | followed by an @r{<ellipsis>} and | |
2738 | an @r{<ellipsis>} is the identifier ``@samp{...}'' (which cannot be used as | |
2739 | an identifier in either a template or a pattern). | |
2740 | @vindex ... | |
2741 | ||
2742 | @emph{Semantics:} An instance of @samp{syntax-rules} produces a new macro | |
2743 | transformer by specifying a sequence of hygienic rewrite rules. A use | |
2744 | of a macro whose keyword is associated with a transformer specified by | |
2745 | @samp{syntax-rules} is matched against the patterns contained in the | |
2746 | @r{<syntax rule>}s, beginning with the leftmost @r{<syntax rule>}. | |
2747 | When a match is found, the macro use is transcribed hygienically | |
2748 | according to the template. | |
2749 | ||
2750 | An identifier that appears in the pattern of a @r{<syntax rule>} is | |
2751 | a @emph{pattern variable}, unless it is the keyword that begins the pattern, | |
2752 | is listed in @r{<literals>}, or is the identifier ``@samp{...}''. | |
2753 | Pattern variables match arbitrary input elements and | |
2754 | are used to refer to elements of the input in the template. It is an | |
2755 | error for the same pattern variable to appear more than once in a | |
2756 | @r{<pattern>}. | |
2757 | ||
2758 | The keyword at the beginning of the pattern in a | |
2759 | @r{<syntax rule>} is not involved in the matching and | |
2760 | is not considered a pattern variable or literal identifier. | |
2761 | ||
2762 | ||
2763 | @quotation | |
2764 | @emph{Rationale:} | |
2765 | The scope of the keyword is determined by the expression or syntax | |
2766 | definition that binds it to the associated macro transformer. | |
2767 | If the keyword were a pattern variable or literal | |
2768 | identifier, then | |
2769 | the template that follows the pattern would be within its scope | |
2770 | regardless of whether the keyword were bound by @samp{let-syntax} | |
2771 | or by @samp{letrec-syntax}. | |
2772 | @end quotation | |
2773 | ||
2774 | ||
2775 | Identifiers that appear in @r{<literals>} are interpreted as literal | |
2776 | identifiers to be matched against corresponding subforms of the input. | |
2777 | A subform | |
2778 | in the input matches a literal identifier if and only if it is an | |
2779 | identifier | |
2780 | and either both its occurrence in the macro expression and its | |
2781 | occurrence in the macro definition have the same lexical binding, or | |
2782 | the two identifiers are equal and both have no lexical binding. | |
2783 | ||
2784 | @c [Bill Rozas suggested the term "noise word" for these literal | |
2785 | @c identifiers, but in their most interesting uses, such as a setf | |
2786 | @c macro, they aren't noise words at all. -- Will] | |
2787 | ||
2788 | A subpattern followed by @samp{...} can match zero or more elements of the | |
2789 | input. It is an error for @samp{...} to appear in @r{<literals>}. | |
2790 | Within a pattern the identifier @samp{...} must follow the last element of | |
2791 | a nonempty sequence of subpatterns. | |
2792 | ||
2793 | More formally, an input form F matches a pattern P if and only if: | |
2794 | ||
2795 | ||
2796 | ||
2797 | @itemize @bullet | |
2798 | ||
2799 | @item | |
2800 | P is a non-literal identifier; or | |
2801 | ||
2802 | @item | |
2803 | P is a literal identifier and F is an identifier with the same | |
2804 | binding; or | |
2805 | ||
2806 | @item | |
2807 | P is a list @samp{(P_1 @dots{} P_n)} and F is a | |
2808 | list of n | |
2809 | forms that match P_1 through P_n, respectively; or | |
2810 | ||
2811 | @item | |
2812 | P is an improper list | |
2813 | @samp{(P_1 P_2 @dots{} P_n . P_n+1)} | |
2814 | and F is a list or | |
2815 | improper list of n or more forms that match P_1 through P_n, | |
2816 | respectively, and whose nth ``cdr'' matches P_n+1; or | |
2817 | ||
2818 | @item | |
2819 | P is of the form | |
2820 | @samp{(P_1 @dots{} P_n P_n+1 <ellipsis>)} | |
2821 | where <ellipsis> is the identifier @samp{...} | |
2822 | and F is | |
2823 | a proper list of at least n forms, the first n of which match | |
2824 | P_1 through P_n, respectively, and each remaining element of F | |
2825 | matches P_n+1; or | |
2826 | ||
2827 | @item | |
2828 | P is a vector of the form @samp{#(P_1 @dots{} P_n)} | |
2829 | and F is a vector | |
2830 | of n forms that match P_1 through P_n; or | |
2831 | ||
2832 | @item | |
2833 | P is of the form | |
2834 | @samp{#(P_1 @dots{} P_n P_n+1 <ellipsis>)} | |
2835 | where <ellipsis> is the identifier @samp{...} | |
2836 | and F is a vector of n | |
2837 | or more forms the first n of which match | |
2838 | P_1 through P_n, respectively, and each remaining element of F | |
2839 | matches P_n+1; or | |
2840 | ||
2841 | @item | |
2842 | P is a datum and F is equal to P in the sense of | |
2843 | the @samp{equal?} procedure. | |
2844 | ||
2845 | @end itemize | |
2846 | ||
2847 | ||
2848 | It is an error to use a macro keyword, within the scope of its | |
2849 | binding, in an expression that does not match any of the patterns. | |
2850 | ||
2851 | When a macro use is transcribed according to the template of the | |
2852 | matching @r{<syntax rule>}, pattern variables that occur in the | |
2853 | template are replaced by the subforms they match in the input. | |
2854 | Pattern variables that occur in subpatterns followed by one or more | |
2855 | instances of the identifier | |
2856 | @samp{...} are allowed only in subtemplates that are | |
2857 | followed by as many instances of @samp{...}. | |
2858 | They are replaced in the | |
2859 | output by all of the subforms they match in the input, distributed as | |
2860 | indicated. It is an error if the output cannot be built up as | |
2861 | specified. | |
2862 | ||
2863 | @c %% This description of output construction is very vague. It should | |
2864 | @c %% probably be formalized, but that is not easy... | |
2865 | ||
2866 | Identifiers that appear in the template but are not pattern variables | |
2867 | or the identifier | |
2868 | @samp{...} are inserted into the output as literal identifiers. If a | |
2869 | literal identifier is inserted as a free identifier then it refers to the | |
2870 | binding of that identifier within whose scope the instance of | |
2871 | @samp{syntax-rules} appears. | |
2872 | If a literal identifier is inserted as a bound identifier then it is | |
2873 | in effect renamed to prevent inadvertent captures of free identifiers. | |
2874 | ||
2875 | As an example, if @code{let} and @code{cond} are defined as in | |
2876 | @vindex @w{cond} | |
2877 | @vindex @w{let} | |
2878 | section @ref{Derived expression type} then they are hygienic (as required) and | |
2879 | the following is not an error. | |
2880 | ||
2881 | ||
2882 | @format | |
2883 | @t{(let ((=> #f)) | |
2884 | (cond (#t => 'ok))) ==> ok | |
2885 | } | |
2886 | @end format | |
2887 | ||
2888 | ||
2889 | The macro transformer for @samp{cond} recognizes @samp{=>} | |
2890 | as a local variable, and hence an expression, and not as the | |
2891 | top-level identifier @samp{=>}, which the macro transformer treats | |
2892 | as a syntactic keyword. Thus the example expands into | |
2893 | ||
2894 | ||
2895 | @format | |
2896 | @t{(let ((=> #f)) | |
2897 | (if #t (begin => 'ok))) | |
2898 | } | |
2899 | @end format | |
2900 | ||
2901 | ||
2902 | instead of | |
2903 | ||
2904 | ||
2905 | @format | |
2906 | @t{(let ((=> #f)) | |
2907 | (let ((temp #t)) | |
2908 | (if temp ('ok temp)))) | |
2909 | } | |
2910 | @end format | |
2911 | ||
2912 | ||
2913 | which would result in an invalid procedure call. | |
2914 | ||
2915 | @end deffn | |
2916 | ||
2917 | ||
2918 | @page | |
2919 | ||
2920 | @c @include{prog} | |
2921 | @node Program structure, Standard procedures, Expressions, top | |
2922 | @chapter Program structure | |
2923 | ||
2924 | @menu | |
2925 | * Programs:: | |
2926 | * Definitions:: | |
2927 | * Syntax definitions:: | |
2928 | @end menu | |
2929 | ||
2930 | ||
2931 | ||
2932 | @node Programs, Definitions, Program structure, Program structure | |
2933 | @section Programs | |
2934 | ||
2935 | ||
2936 | A Scheme program consists of a sequence of expressions, definitions, | |
2937 | and syntax definitions. | |
2938 | Expressions are described in chapter @ref{Expressions}; | |
2939 | definitions and syntax definitions are the subject of the rest of the | |
2940 | present chapter. | |
2941 | ||
2942 | Programs are typically stored in files or entered interactively to a | |
2943 | running Scheme system, although other paradigms are possible; | |
2944 | questions of user interface lie outside the scope of this report. | |
2945 | (Indeed, Scheme would still be useful as a notation for expressing | |
2946 | computational methods even in the absence of a mechanical | |
2947 | implementation.) | |
2948 | ||
2949 | Definitions and syntax definitions occurring at the top level of a program | |
2950 | can be interpreted | |
2951 | declaratively. | |
2952 | They cause bindings to be created in the top level | |
2953 | environment or modify the value of existing top-level bindings. | |
2954 | Expressions occurring at the top level of a program are | |
2955 | interpreted imperatively; they are executed in order when the program is | |
2956 | invoked or loaded, and typically perform some kind of initialization. | |
2957 | ||
2958 | At the top level of a program @t{(begin @r{<form1>} @dots{},)} is | |
2959 | equivalent to the sequence of expressions, definitions, and syntax definitions | |
2960 | that form the body of the @code{begin}. | |
2961 | @vindex @w{begin} | |
2962 | ||
2963 | @ignore todo | |
2964 | Cromarty, etc.: disclaimer about top level? | |
2965 | @end ignore | |
2966 | ||
2967 | ||
2968 | @node Definitions, Syntax definitions, Programs, Program structure | |
2969 | @section Definitions | |
2970 | ||
2971 | @menu | |
2972 | * Top level definitions:: | |
2973 | * Internal definitions:: | |
2974 | @end menu | |
2975 | ||
2976 | ||
2977 | ||
2978 | Definitions are valid in some, but not all, contexts where expressions | |
2979 | are allowed. They are valid only at the top level of a @r{<program>} | |
2980 | and at the beginning of a @r{<body>}. | |
2981 | ||
2982 | @cindex @w{definition} | |
2983 | ||
2984 | A definition should have one of the following forms: | |
2985 | @cindex @w{define} | |
2986 | ||
2987 | ||
2988 | ||
2989 | @itemize @bullet | |
2990 | ||
2991 | ||
2992 | @item @t{(define @r{<variable>} @r{<expression>})} | |
2993 | ||
2994 | @item @t{(define (@r{<variable>} @r{<formals>}) @r{<body>})} | |
2995 | ||
2996 | @r{<Formals>} should be either a | |
2997 | sequence of zero or more variables, or a sequence of one or more | |
2998 | variables followed by a space-delimited period and another variable (as | |
2999 | in a lambda expression). This form is equivalent to | |
3000 | ||
3001 | @example | |
3002 | ||
3003 | (define @r{<variable>} | |
3004 | (lambda (@r{<formals>}) @r{<body>}))@r{.} | |
3005 | ||
3006 | @end example | |
3007 | ||
3008 | ||
3009 | @item @t{(define (@r{<variable>} .@: @r{<formal>}) @r{<body>})} | |
3010 | ||
3011 | @r{<Formal>} should be a single | |
3012 | variable. This form is equivalent to | |
3013 | ||
3014 | @example | |
3015 | ||
3016 | (define @r{<variable>} | |
3017 | (lambda @r{<formal>} @r{<body>}))@r{.} | |
3018 | ||
3019 | @end example | |
3020 | ||
3021 | ||
3022 | ||
3023 | @end itemize | |
3024 | ||
3025 | ||
3026 | @node Top level definitions, Internal definitions, Definitions, Definitions | |
3027 | @subsection Top level definitions | |
3028 | ||
3029 | ||
3030 | At the top level of a program, a definition | |
3031 | ||
3032 | @example | |
3033 | ||
3034 | (define @r{<variable>} @r{<expression>}) | |
3035 | ||
3036 | @end example | |
3037 | ||
3038 | has essentially the same effect as the assignment expression | |
3039 | ||
3040 | @example | |
3041 | ||
3042 | (set! @r{<variable>} @r{<expression>}) | |
3043 | ||
3044 | @end example | |
3045 | ||
3046 | if @r{<variable>} is bound. If @r{<variable>} is not bound, | |
3047 | however, then the definition will bind @r{<variable>} to a new | |
3048 | location before performing the assignment, whereas it would be an error | |
3049 | to perform a @samp{set!} on an unbound variable. | |
3050 | @cindex @w{unbound} | |
3051 | ||
3052 | ||
3053 | @example | |
3054 | ||
3055 | (define add3 | |
3056 | (lambda (x) (+ x 3))) | |
3057 | (add3 3) ==> 6 | |
3058 | (define first car) | |
3059 | (first '(1 2)) ==> 1 | |
3060 | ||
3061 | @end example | |
3062 | ||
3063 | ||
3064 | Some implementations of Scheme use an initial environment in | |
3065 | which all possible variables are bound to locations, most of | |
3066 | which contain undefined values. Top level definitions in | |
3067 | such an implementation are truly equivalent to assignments. | |
3068 | ||
3069 | @ignore todo | |
3070 | Rozas: equal time for opposition semantics? | |
3071 | @end ignore | |
3072 | ||
3073 | ||
3074 | ||
3075 | @node Internal definitions, , Top level definitions, Definitions | |
3076 | @subsection Internal definitions | |
3077 | ||
3078 | ||
3079 | ||
3080 | Definitions may occur at the | |
3081 | beginning of a @r{<body>} (that is, the body of a @code{lambda}, | |
3082 | @vindex @w{lambda} | |
3083 | @code{let}, @code{let*}, @code{letrec}, @code{let-syntax}, or @code{letrec-syntax} | |
3084 | @vindex @w{letrec-syntax} | |
3085 | @vindex @w{let-syntax} | |
3086 | @vindex @w{letrec} | |
3087 | @vindex @w{let*} | |
3088 | @vindex @w{let} | |
3089 | expression or that of a definition of an appropriate form). | |
3090 | Such definitions are known as @emph{internal definitions} as opposed to the top level definitions described above. | |
3091 | @cindex @w{internal definition} | |
3092 | The variable defined by an internal definition is local to the | |
3093 | @r{<body>}. That is, @r{<variable>} is bound rather than assigned, | |
3094 | and the region of the binding is the entire @r{<body>}. For example, | |
3095 | ||
3096 | ||
3097 | @example | |
3098 | ||
3099 | (let ((x 5)) | |
3100 | (define foo (lambda (y) (bar x y))) | |
3101 | (define bar (lambda (a b) (+ (* a b) a))) | |
3102 | (foo (+ x 3))) ==> 45 | |
3103 | ||
3104 | @end example | |
3105 | ||
3106 | ||
3107 | A @r{<body>} containing internal definitions can always be converted | |
3108 | into a completely equivalent @samp{letrec} expression. For example, the | |
3109 | @samp{let} expression in the above example is equivalent to | |
3110 | ||
3111 | ||
3112 | @example | |
3113 | ||
3114 | (let ((x 5)) | |
3115 | (letrec ((foo (lambda (y) (bar x y))) | |
3116 | (bar (lambda (a b) (+ (* a b) a)))) | |
3117 | (foo (+ x 3)))) | |
3118 | ||
3119 | @end example | |
3120 | ||
3121 | ||
3122 | Just as for the equivalent @samp{letrec} expression, it must be | |
3123 | possible to evaluate each @r{<expression>} of every internal | |
3124 | definition in a @r{<body>} without assigning or referring to | |
3125 | the value of any @r{<variable>} being defined. | |
3126 | ||
3127 | Wherever an internal definition may occur | |
3128 | @t{(begin @r{<definition1>} @dots{},)} | |
3129 | is equivalent to the sequence of definitions | |
3130 | that form the body of the @code{begin}. | |
3131 | @vindex @w{begin} | |
3132 | ||
3133 | @node Syntax definitions, , Definitions, Program structure | |
3134 | @section Syntax definitions | |
3135 | ||
3136 | ||
3137 | Syntax definitions are valid only at the top level of a @r{<program>}. | |
3138 | ||
3139 | @cindex @w{syntax definition} | |
3140 | They have the following form: | |
3141 | @cindex @w{define-syntax} | |
3142 | ||
3143 | @t{(define-syntax @r{<keyword>} @r{<transformer spec>})} | |
3144 | ||
3145 | @r{<Keyword>} is an identifier, and | |
3146 | the @r{<transformer spec>} should be an instance of @code{syntax-rules}. | |
3147 | @vindex @w{syntax-rules} | |
3148 | The top-level syntactic environment is extended by binding the | |
3149 | @r{<keyword>} to the specified transformer. | |
3150 | ||
3151 | There is no @samp{define-syntax} analogue of internal definitions. | |
3152 | ||
3153 | @c [Rationale flushed because it may or may not be true and isn't the | |
3154 | @c real rationale anyway. -RK] | |
3155 | @c \begin{rationale} | |
3156 | @c As discussed below, the syntax and scope rules for syntax definitions | |
3157 | @c can give rise to syntactic ambiguities when syntactic keywords are | |
3158 | @c shadowed. | |
3159 | @c Further ambiguities would arise if {\cf define-syntax} | |
3160 | @c were permitted at the beginning of a \meta{body}, with scope | |
3161 | @c rules analogous to those for internal definitions. | |
3162 | @c \end{rationale} | |
3163 | ||
3164 | @c It is an error for a program to contain more than one top-level | |
3165 | @c \meta{definition} or \meta{syntax definition} of any identifier. | |
3166 | ||
3167 | @c [I flushed this because it isn't an error for a program to | |
3168 | @c contain more than one top-level definition of an identifier, | |
3169 | @c and I didn't want to introduce any gratuitous incompatibilities | |
3170 | @c with the existing Scheme language. -- Will] | |
3171 | ||
3172 | Although macros may expand into definitions and syntax definitions in | |
3173 | any context that permits them, it is an error for a definition or syntax | |
3174 | definition to shadow a syntactic keyword whose meaning is needed to | |
3175 | determine whether some form in the group of forms that contains the | |
3176 | shadowing definition is in fact a definition, or, for internal definitions, | |
3177 | is needed to determine the boundary between the group and the expressions | |
3178 | that follow the group. For example, the following are errors: | |
3179 | ||
3180 | ||
3181 | @example | |
3182 | ||
3183 | (define define 3) | |
3184 | ||
3185 | (begin (define begin list)) | |
3186 | ||
3187 | (let-syntax | |
3188 | ((foo (syntax-rules () | |
3189 | ((foo (proc args ...) body ...) | |
3190 | (define proc | |
3191 | (lambda (args ...) | |
3192 | body ...)))))) | |
3193 | (let ((x 3)) | |
3194 | (foo (plus x y) (+ x y)) | |
3195 | (define foo x) | |
3196 | (plus foo x))) | |
3197 | ||
3198 | @end example | |
3199 | ||
3200 | ||
3201 | ||
3202 | ||
3203 | @c @include{procs} | |
3204 | ||
3205 | @c Initial environment | |
3206 | ||
3207 | @c \vfill\eject | |
3208 | @node Standard procedures, Formal syntax and semantics, Program structure, top | |
3209 | @chapter Standard procedures | |
3210 | ||
3211 | @menu | |
3212 | * Equivalence predicates:: | |
3213 | * Numbers:: | |
3214 | * Other data types:: | |
3215 | * Control features:: | |
3216 | * Eval:: | |
3217 | * Input and output:: | |
3218 | @end menu | |
3219 | ||
3220 | ||
3221 | ||
3222 | ||
3223 | ||
3224 | @cindex @w{initial environment} | |
3225 | ||
3226 | @cindex @w{top level environment} | |
3227 | ||
3228 | @cindex @w{library procedure} | |
3229 | ||
3230 | This chapter describes Scheme's built-in procedures. The initial (or | |
3231 | ``top level'') Scheme environment starts out with a number of variables | |
3232 | bound to locations containing useful values, most of which are primitive | |
3233 | procedures that manipulate data. For example, the variable @samp{abs} is | |
3234 | bound to (a location initially containing) a procedure of one argument | |
3235 | that computes the absolute value of a number, and the variable @samp{+} | |
3236 | is bound to a procedure that computes sums. Built-in procedures that | |
3237 | can easily be written in terms of other built-in procedures are identified as | |
3238 | ``library procedures''. | |
3239 | ||
3240 | A program may use a top-level definition to bind any variable. It may | |
3241 | subsequently alter any such binding by an assignment (see @pxref{Assignments}). | |
3242 | These operations do not modify the behavior of Scheme's built-in | |
3243 | procedures. Altering any top-level binding that has not been introduced by a | |
3244 | definition has an unspecified effect on the behavior of the built-in procedures. | |
3245 | ||
3246 | @node Equivalence predicates, Numbers, Standard procedures, Standard procedures | |
3247 | @section Equivalence predicates | |
3248 | ||
3249 | ||
3250 | ||
3251 | A @dfn{predicate} is a procedure that always returns a boolean | |
3252 | @cindex @w{predicate} | |
3253 | value (@t{#t} or @t{#f}). An @dfn{equivalence predicate} is | |
3254 | @cindex @w{equivalence predicate} | |
3255 | the computational analogue of a mathematical equivalence relation (it is | |
3256 | symmetric, reflexive, and transitive). Of the equivalence predicates | |
3257 | described in this section, @samp{eq?} is the finest or most | |
3258 | discriminating, and @samp{equal?} is the coarsest. @samp{Eqv?} is | |
3259 | slightly less discriminating than @samp{eq?}. | |
3260 | @ignore todo | |
3261 | Pitman doesn't like | |
3262 | this paragraph. Lift the discussion from the Maclisp manual. Explain | |
3263 | why there's more than one predicate. | |
3264 | @end ignore | |
3265 | ||
3266 | ||
3267 | ||
3268 | ||
3269 | @deffn {procedure} eqv? obj1 obj2 | |
3270 | ||
3271 | The @samp{eqv?} procedure defines a useful equivalence relation on objects. | |
3272 | Briefly, it returns @t{#t} if @var{obj1} and @var{obj2} should | |
3273 | normally be regarded as the same object. This relation is left slightly | |
3274 | open to interpretation, but the following partial specification of | |
3275 | @samp{eqv?} holds for all implementations of Scheme. | |
3276 | ||
3277 | The @samp{eqv?} procedure returns @t{#t} if: | |
3278 | ||
3279 | ||
3280 | ||
3281 | @itemize @bullet | |
3282 | ||
3283 | @item | |
3284 | @var{obj1} and @var{obj2} are both @t{#t} or both @t{#f}. | |
3285 | ||
3286 | @item | |
3287 | @var{obj1} and @var{obj2} are both symbols and | |
3288 | ||
3289 | ||
3290 | @format | |
3291 | @t{(string=? (symbol->string obj1) | |
3292 | (symbol->string obj2)) | |
3293 | ==> #t | |
3294 | } | |
3295 | @end format | |
3296 | ||
3297 | ||
3298 | ||
3299 | @quotation | |
3300 | @emph{Note:} | |
3301 | This assumes that neither @var{obj1} nor @var{obj2} is an ``uninterned | |
3302 | symbol'' as alluded to in section @ref{Symbols}. This report does | |
3303 | not presume to specify the behavior of @samp{eqv?} on implementation-dependent | |
3304 | extensions. | |
3305 | @end quotation | |
3306 | ||
3307 | ||
3308 | @item | |
3309 | @var{obj1} and @var{obj2} are both numbers, are numerically | |
3310 | equal (see @samp{=}, section @pxref{Numbers}), and are either both | |
3311 | exact or both inexact. | |
3312 | ||
3313 | @item | |
3314 | @var{obj1} and @var{obj2} are both characters and are the same | |
3315 | character according to the @samp{char=?} procedure | |
3316 | (section @pxref{Characters}). | |
3317 | ||
3318 | @item | |
3319 | both @var{obj1} and @var{obj2} are the empty list. | |
3320 | ||
3321 | @item | |
3322 | @var{obj1} and @var{obj2} are pairs, vectors, or strings that denote the | |
3323 | same locations in the store (section @pxref{Storage model}). | |
3324 | ||
3325 | @item | |
3326 | @var{obj1} and @var{obj2} are procedures whose location tags are | |
3327 | equal (section @pxref{Procedures}). | |
3328 | ||
3329 | @end itemize | |
3330 | ||
3331 | @cindex @w{inexact} | |
3332 | @cindex @w{exact} | |
3333 | ||
3334 | The @samp{eqv?} procedure returns @t{#f} if: | |
3335 | ||
3336 | ||
3337 | ||
3338 | @itemize @bullet | |
3339 | ||
3340 | @item | |
3341 | @var{obj1} and @var{obj2} are of different types | |
3342 | (section @pxref{Disjointness of types}). | |
3343 | ||
3344 | @item | |
3345 | one of @var{obj1} and @var{obj2} is @t{#t} but the other is | |
3346 | @t{#f}. | |
3347 | ||
3348 | @item | |
3349 | @var{obj1} and @var{obj2} are symbols but | |
3350 | ||
3351 | ||
3352 | @format | |
3353 | @t{(string=? (symbol->string @var{obj1}) | |
3354 | (symbol->string @var{obj2})) | |
3355 | ==> #f | |
3356 | } | |
3357 | @end format | |
3358 | ||
3359 | ||
3360 | @item | |
3361 | one of @var{obj1} and @var{obj2} is an exact number but the other | |
3362 | is an inexact number. | |
3363 | ||
3364 | @item | |
3365 | @var{obj1} and @var{obj2} are numbers for which the @samp{=} | |
3366 | procedure returns @t{#f}. | |
3367 | ||
3368 | @item | |
3369 | @var{obj1} and @var{obj2} are characters for which the @samp{char=?} | |
3370 | procedure returns @t{#f}. | |
3371 | ||
3372 | @item | |
3373 | one of @var{obj1} and @var{obj2} is the empty list but the other | |
3374 | is not. | |
3375 | ||
3376 | @item | |
3377 | @var{obj1} and @var{obj2} are pairs, vectors, or strings that denote | |
3378 | distinct locations. | |
3379 | ||
3380 | @item | |
3381 | @var{obj1} and @var{obj2} are procedures that would behave differently | |
3382 | (return different value(s) or have different side effects) for some arguments. | |
3383 | ||
3384 | ||
3385 | @end itemize | |
3386 | ||
3387 | ||
3388 | ||
3389 | @format | |
3390 | @t{(eqv? 'a 'a) ==> #t | |
3391 | (eqv? 'a 'b) ==> #f | |
3392 | (eqv? 2 2) ==> #t | |
3393 | (eqv? '() '()) ==> #t | |
3394 | (eqv? 100000000 100000000) ==> #t | |
3395 | (eqv? (cons 1 2) (cons 1 2)) ==> #f | |
3396 | (eqv? (lambda () 1) | |
3397 | (lambda () 2)) ==> #f | |
3398 | (eqv? #f 'nil) ==> #f | |
3399 | (let ((p (lambda (x) x))) | |
3400 | (eqv? p p)) ==> #t | |
3401 | } | |
3402 | @end format | |
3403 | ||
3404 | ||
3405 | The following examples illustrate cases in which the above rules do | |
3406 | not fully specify the behavior of @samp{eqv?}. All that can be said | |
3407 | about such cases is that the value returned by @samp{eqv?} must be a | |
3408 | boolean. | |
3409 | ||
3410 | ||
3411 | @format | |
3412 | @t{(eqv? "" "") ==> @emph{unspecified} | |
3413 | (eqv? '#() '#()) ==> @emph{unspecified} | |
3414 | (eqv? (lambda (x) x) | |
3415 | (lambda (x) x)) ==> @emph{unspecified} | |
3416 | (eqv? (lambda (x) x) | |
3417 | (lambda (y) y)) ==> @emph{unspecified} | |
3418 | } | |
3419 | @end format | |
3420 | ||
3421 | ||
3422 | The next set of examples shows the use of @samp{eqv?} with procedures | |
3423 | that have local state. @samp{Gen-counter} must return a distinct | |
3424 | procedure every time, since each procedure has its own internal counter. | |
3425 | @samp{Gen-loser}, however, returns equivalent procedures each time, since | |
3426 | the local state does not affect the value or side effects of the | |
3427 | procedures. | |
3428 | ||
3429 | ||
3430 | @format | |
3431 | @t{(define gen-counter | |
3432 | (lambda () | |
3433 | (let ((n 0)) | |
3434 | (lambda () (set! n (+ n 1)) n)))) | |
3435 | (let ((g (gen-counter))) | |
3436 | (eqv? g g)) ==> #t | |
3437 | (eqv? (gen-counter) (gen-counter)) | |
3438 | ==> #f | |
3439 | (define gen-loser | |
3440 | (lambda () | |
3441 | (let ((n 0)) | |
3442 | (lambda () (set! n (+ n 1)) 27)))) | |
3443 | (let ((g (gen-loser))) | |
3444 | (eqv? g g)) ==> #t | |
3445 | (eqv? (gen-loser) (gen-loser)) | |
3446 | ==> @emph{unspecified} | |
3447 | ||
3448 | (letrec ((f (lambda () (if (eqv? f g) 'both 'f))) | |
3449 | (g (lambda () (if (eqv? f g) 'both 'g)))) | |
3450 | (eqv? f g)) | |
3451 | ==> @emph{unspecified} | |
3452 | ||
3453 | (letrec ((f (lambda () (if (eqv? f g) 'f 'both))) | |
3454 | (g (lambda () (if (eqv? f g) 'g 'both)))) | |
3455 | (eqv? f g)) | |
3456 | ==> #f | |
3457 | } | |
3458 | @end format | |
3459 | ||
3460 | ||
3461 | @c Objects of distinct types must never be regarded as the same object, | |
3462 | @c except that \schfalse{} and the empty list\index{empty list} are permitted to | |
3463 | @c be identical. | |
3464 | ||
3465 | @c \begin{scheme} | |
3466 | @c (eqv? '() \schfalse) \ev \unspecified% | |
3467 | @c \end{scheme} | |
3468 | ||
3469 | Since it is an error to modify constant objects (those returned by | |
3470 | literal expressions), implementations are permitted, though not | |
3471 | required, to share structure between constants where appropriate. Thus | |
3472 | the value of @samp{eqv?} on constants is sometimes | |
3473 | implementation-dependent. | |
3474 | ||
3475 | ||
3476 | @format | |
3477 | @t{(eqv? '(a) '(a)) ==> @emph{unspecified} | |
3478 | (eqv? "a" "a") ==> @emph{unspecified} | |
3479 | (eqv? '(b) (cdr '(a b))) ==> @emph{unspecified} | |
3480 | (let ((x '(a))) | |
3481 | (eqv? x x)) ==> #t | |
3482 | } | |
3483 | @end format | |
3484 | ||
3485 | ||
3486 | ||
3487 | @quotation | |
3488 | @emph{Rationale:} | |
3489 | The above definition of @samp{eqv?} allows implementations latitude in | |
3490 | their treatment of procedures and literals: implementations are free | |
3491 | either to detect or to fail to detect that two procedures or two literals | |
3492 | are equivalent to each other, and can decide whether or not to | |
3493 | merge representations of equivalent objects by using the same pointer or | |
3494 | bit pattern to represent both. | |
3495 | @end quotation | |
3496 | ||
3497 | ||
3498 | @end deffn | |
3499 | ||
3500 | ||
3501 | ||
3502 | @deffn {procedure} eq? obj1 obj2 | |
3503 | ||
3504 | @samp{Eq?} is similar to @samp{eqv?} except that in some cases it is | |
3505 | capable of discerning distinctions finer than those detectable by | |
3506 | @samp{eqv?}. | |
3507 | ||
3508 | @samp{Eq?} and @samp{eqv?} are guaranteed to have the same | |
3509 | behavior on symbols, booleans, the empty list, pairs, procedures, | |
3510 | and non-empty | |
3511 | strings and vectors. @samp{Eq?}'s behavior on numbers and characters is | |
3512 | implementation-dependent, but it will always return either true or | |
3513 | false, and will return true only when @samp{eqv?} would also return | |
3514 | true. @samp{Eq?} may also behave differently from @samp{eqv?} on empty | |
3515 | vectors and empty strings. | |
3516 | ||
3517 | ||
3518 | @format | |
3519 | @t{(eq? 'a 'a) ==> #t | |
3520 | (eq? '(a) '(a)) ==> @emph{unspecified} | |
3521 | (eq? (list 'a) (list 'a)) ==> #f | |
3522 | (eq? "a" "a") ==> @emph{unspecified} | |
3523 | (eq? "" "") ==> @emph{unspecified} | |
3524 | (eq? '() '()) ==> #t | |
3525 | (eq? 2 2) ==> @emph{unspecified} | |
3526 | (eq? #\A #\A) ==> @emph{unspecified} | |
3527 | (eq? car car) ==> #t | |
3528 | (let ((n (+ 2 3))) | |
3529 | (eq? n n)) ==> @emph{unspecified} | |
3530 | (let ((x '(a))) | |
3531 | (eq? x x)) ==> #t | |
3532 | (let ((x '#())) | |
3533 | (eq? x x)) ==> #t | |
3534 | (let ((p (lambda (x) x))) | |
3535 | (eq? p p)) ==> #t | |
3536 | } | |
3537 | @end format | |
3538 | ||
3539 | ||
3540 | @ignore todo | |
3541 | Needs to be explained better above. How can this be made to be | |
3542 | not confusing? A table maybe? | |
3543 | @end ignore | |
3544 | ||
3545 | ||
3546 | ||
3547 | @quotation | |
3548 | @emph{Rationale:} It will usually be possible to implement @samp{eq?} much | |
3549 | more efficiently than @samp{eqv?}, for example, as a simple pointer | |
3550 | comparison instead of as some more complicated operation. One reason is | |
3551 | that it may not be possible to compute @samp{eqv?} of two numbers in | |
3552 | constant time, whereas @samp{eq?} implemented as pointer comparison will | |
3553 | always finish in constant time. @samp{Eq?} may be used like @samp{eqv?} | |
3554 | in applications using procedures to implement objects with state since | |
3555 | it obeys the same constraints as @samp{eqv?}. | |
3556 | @end quotation | |
3557 | ||
3558 | ||
3559 | @end deffn | |
3560 | ||
3561 | ||
3562 | ||
3563 | @deffn {library procedure} equal? obj1 obj2 | |
3564 | ||
3565 | @samp{Equal?} recursively compares the contents of pairs, vectors, and | |
3566 | strings, applying @samp{eqv?} on other objects such as numbers and symbols. | |
3567 | A rule of thumb is that objects are generally @samp{equal?} if they print | |
3568 | the same. @samp{Equal?} may fail to terminate if its arguments are | |
3569 | circular data structures. | |
3570 | ||
3571 | ||
3572 | @format | |
3573 | @t{(equal? 'a 'a) ==> #t | |
3574 | (equal? '(a) '(a)) ==> #t | |
3575 | (equal? '(a (b) c) | |
3576 | '(a (b) c)) ==> #t | |
3577 | (equal? "abc" "abc") ==> #t | |
3578 | (equal? 2 2) ==> #t | |
3579 | (equal? (make-vector 5 'a) | |
3580 | (make-vector 5 'a)) ==> #t | |
3581 | (equal? (lambda (x) x) | |
3582 | (lambda (y) y)) ==> @emph{unspecified} | |
3583 | } | |
3584 | @end format | |
3585 | ||
3586 | ||
3587 | @end deffn | |
3588 | ||
3589 | ||
3590 | @node Numbers, Other data types, Equivalence predicates, Standard procedures | |
3591 | @section Numbers | |
3592 | ||
3593 | @menu | |
3594 | * Numerical types:: | |
3595 | * Exactness:: | |
3596 | * Implementation restrictions:: | |
3597 | * Syntax of numerical constants:: | |
3598 | * Numerical operations:: | |
3599 | * Numerical input and output:: | |
3600 | @end menu | |
3601 | ||
3602 | ||
3603 | ||
3604 | @cindex @w{number} | |
3605 | ||
3606 | @c %R4%% The excessive use of the code font in this section was | |
3607 | @c confusing, somewhat obnoxious, and inconsistent with the rest | |
3608 | @c of the report and with parts of the section itself. I added | |
3609 | @c a \tupe no-op, and changed most old uses of \type to \tupe, | |
3610 | @c to make it easier to change the fonts back if people object | |
3611 | @c to the change. | |
3612 | ||
3613 | @c \newcommand{\type}[1]{{\it#1}} | |
3614 | @c \newcommand{\tupe}[1]{{#1}} | |
3615 | ||
3616 | Numerical computation has traditionally been neglected by the Lisp | |
3617 | community. Until Common Lisp there was no carefully thought out | |
3618 | strategy for organizing numerical computation, and with the exception of | |
3619 | the MacLisp system [Pitman83] little effort was made to | |
3620 | execute numerical code efficiently. This report recognizes the excellent work | |
3621 | of the Common Lisp committee and accepts many of their recommendations. | |
3622 | In some ways this report simplifies and generalizes their proposals in a manner | |
3623 | consistent with the purposes of Scheme. | |
3624 | ||
3625 | It is important to distinguish between the mathematical numbers, the | |
3626 | Scheme numbers that attempt to model them, the machine representations | |
3627 | used to implement the Scheme numbers, and notations used to write numbers. | |
3628 | This report uses the types @i{number}, @i{complex}, @i{real}, | |
3629 | @i{rational}, and @i{integer} to refer to both mathematical numbers | |
3630 | and Scheme numbers. Machine representations such as fixed point and | |
3631 | floating point are referred to by names such as @i{fixnum} and | |
3632 | @i{flonum}. | |
3633 | ||
3634 | @c %R4%% I did some reorganizing here to move the discussion of mathematical | |
3635 | @c numbers before the discussion of the Scheme numbers, hoping that this | |
3636 | @c would help to motivate the discussion of representation independence. | |
3637 | ||
3638 | @node Numerical types, Exactness, Numbers, Numbers | |
3639 | @subsection Numerical types | |
3640 | ||
3641 | ||
3642 | ||
3643 | @cindex @w{numerical types} | |
3644 | ||
3645 | @c %R4%% A Scheme system provides data of type \type{number}, which is the most | |
3646 | @c general numerical type supported by that system. | |
3647 | @c \type{Number} is | |
3648 | @c likely to be a complicated union type implemented in terms of | |
3649 | @c \type{fixnum}s, \type{bignum}s, \type{flonum}s, and so forth, but this | |
3650 | @c should not be apparent to a naive user. What the user should see is | |
3651 | @c that the usual operations on numbers produce the mathematically | |
3652 | @c expected results, within the limits of the implementation. | |
3653 | ||
3654 | @c %R4%% I rewrote the following paragraph to make the various levels of | |
3655 | @c the tower into subsets of each other, instead of relating them by | |
3656 | @c injections. I think the injections tended to put people in the frame | |
3657 | @c of mind of thinking about coercions between non-overlapping numeric | |
3658 | @c types in mainstream programming languages. | |
3659 | ||
3660 | Mathematically, numbers may be arranged into a tower of subtypes | |
3661 | @c %R4%% with injections relating adjacent levels of the tower: | |
3662 | in which each level is a subset of the level above it: | |
3663 | ||
3664 | @format | |
3665 | @r{number} | |
3666 | @r{complex} | |
3667 | @r{real} | |
3668 | @r{rational} | |
3669 | @r{integer} | |
3670 | @end format | |
3671 | ||
3672 | ||
3673 | For example, 3 is an integer. Therefore 3 is also a rational, | |
3674 | a real, and a complex. The same is true of the Scheme numbers | |
3675 | that model 3. For Scheme numbers, these types are defined by the | |
3676 | predicates @code{number?}, @code{complex?}, @code{real?}, @code{rational?}, | |
3677 | @vindex @w{rational?} | |
3678 | @vindex @w{real?} | |
3679 | @vindex @w{complex?} | |
3680 | @vindex @w{number?} | |
3681 | and @code{integer?}. | |
3682 | @vindex @w{integer?} | |
3683 | ||
3684 | There is no simple relationship between a number's type and its | |
3685 | representation inside a computer. Although most implementations of | |
3686 | Scheme will offer at least two different representations of 3, these | |
3687 | different representations denote the same integer. | |
3688 | ||
3689 | @c %R4%% I moved "Implementations of Scheme are not required to implement | |
3690 | @c the whole tower..." to the subsection on implementation restrictions. | |
3691 | ||
3692 | Scheme's numerical operations treat numbers as abstract data, as | |
3693 | independent of their representation as possible. Although an implementation | |
3694 | of Scheme may use fixnum, flonum, and perhaps other representations for | |
3695 | numbers, this should not be apparent to a casual programmer writing | |
3696 | simple programs. | |
3697 | ||
3698 | It is necessary, however, to distinguish between numbers that are | |
3699 | represented exactly and those that may not be. For example, indexes | |
3700 | into data structures must be known exactly, as must some polynomial | |
3701 | coefficients in a symbolic algebra system. On the other hand, the | |
3702 | results of measurements are inherently inexact, and irrational numbers | |
3703 | may be approximated by rational and therefore inexact approximations. | |
3704 | In order to catch uses of inexact numbers where exact numbers are | |
3705 | required, Scheme explicitly distinguishes exact from inexact numbers. | |
3706 | This distinction is orthogonal to the dimension of type. | |
3707 | ||
3708 | @node Exactness, Implementation restrictions, Numerical types, Numbers | |
3709 | @subsection Exactness | |
3710 | ||
3711 | ||
3712 | @c %R4%% I tried to direct the following paragraph away from philosophizing | |
3713 | @c about the exactness of mathematical numbers, and toward philosophizing | |
3714 | @c about the exactness of Scheme numbers. | |
3715 | ||
3716 | ||
3717 | @cindex @w{exactness} | |
3718 | Scheme numbers are either @i{exact} or @i{inexact}. A number is | |
3719 | @r{exact} if it was written as an exact constant or was derived from | |
3720 | @r{exact} numbers using only @r{exact} operations. A number is | |
3721 | @r{inexact} if it was written as an inexact constant, | |
3722 | @c %R4%% models a quantity (e.g., a measurement) known only approximately, | |
3723 | if it was | |
3724 | derived using @r{inexact} ingredients, or if it was derived using | |
3725 | @r{inexact} operations. Thus @r{inexact}ness is a contagious | |
3726 | property of a number. | |
3727 | @c %R4%% The rest of this paragraph (from R3RS) has been dropped. | |
3728 | ||
3729 | If two implementations produce @r{exact} results for a | |
3730 | computation that did not involve @r{inexact} intermediate results, | |
3731 | the two ultimate results will be mathematically equivalent. This is | |
3732 | generally not true of computations involving @r{inexact} numbers | |
3733 | since approximate methods such as floating point arithmetic may be used, | |
3734 | but it is the duty of each implementation to make the result as close as | |
3735 | practical to the mathematically ideal result. | |
3736 | ||
3737 | Rational operations such as @samp{+} should always produce | |
3738 | @r{exact} results when given @r{exact} arguments. | |
3739 | @c %R4%%If an implementation is | |
3740 | @c unable to represent an \tupe{exact} result (for example, if it does not | |
3741 | @c support infinite precision integers and rationals) | |
3742 | If the operation is unable to produce an @r{exact} result, | |
3743 | then it may either report the violation of an implementation restriction | |
3744 | or it may silently coerce its | |
3745 | result to an @r{inexact} value. | |
3746 | @c %R4%%Such a coercion may cause an error later. | |
3747 | See section @ref{Implementation restrictions}. | |
3748 | ||
3749 | With the exception of @code{inexact->exact}, the operations described in | |
3750 | @vindex @w{inexact->exact} | |
3751 | this section must generally return inexact results when given any inexact | |
3752 | arguments. An operation may, however, return an @r{exact} result if it can | |
3753 | prove that the value of the result is unaffected by the inexactness of its | |
3754 | arguments. For example, multiplication of any number by an @r{exact} zero | |
3755 | may produce an @r{exact} zero result, even if the other argument is | |
3756 | @r{inexact}. | |
3757 | ||
3758 | @node Implementation restrictions, Syntax of numerical constants, Exactness, Numbers | |
3759 | @subsection Implementation restrictions | |
3760 | ||
3761 | ||
3762 | ||
3763 | @cindex @w{implementation restriction} | |
3764 | ||
3765 | Implementations of Scheme are not required to implement the whole | |
3766 | tower of subtypes given in section @ref{Numerical types}, | |
3767 | but they must implement a coherent subset consistent with both the | |
3768 | purposes of the implementation and the spirit of the Scheme language. | |
3769 | For example, an implementation in which all numbers are @r{real} | |
3770 | may still be quite useful. | |
3771 | ||
3772 | Implementations may also support only a limited range of numbers of | |
3773 | any type, subject to the requirements of this section. The supported | |
3774 | range for @r{exact} numbers of any type may be different from the | |
3775 | supported range for @r{inexact} numbers of that type. For example, | |
3776 | an implementation that uses flonums to represent all its | |
3777 | @r{inexact} @r{real} numbers may | |
3778 | support a practically unbounded range of @r{exact} @r{integer}s | |
3779 | and @r{rational}s | |
3780 | while limiting the range of @r{inexact} @r{real}s (and therefore | |
3781 | the range of @r{inexact} @r{integer}s and @r{rational}s) | |
3782 | to the dynamic range of the flonum format. | |
3783 | Furthermore | |
3784 | the gaps between the representable @r{inexact} @r{integer}s and | |
3785 | @r{rational}s are | |
3786 | likely to be very large in such an implementation as the limits of this | |
3787 | range are approached. | |
3788 | ||
3789 | An implementation of Scheme must support exact integers | |
3790 | throughout the range of numbers that may be used for indexes of | |
3791 | lists, vectors, and strings or that may result from computing the length of a | |
3792 | list, vector, or string. The @code{length}, @code{vector-length}, | |
3793 | @vindex @w{vector-length} | |
3794 | @vindex @w{length} | |
3795 | and @code{string-length} procedures must return an exact | |
3796 | @vindex @w{string-length} | |
3797 | integer, and it is an error to use anything but an exact integer as an | |
3798 | index. Furthermore any integer constant within the index range, if | |
3799 | expressed by an exact integer syntax, will indeed be read as an exact | |
3800 | integer, regardless of any implementation restrictions that may apply | |
3801 | outside this range. Finally, the procedures listed below will always | |
3802 | return an exact integer result provided all their arguments are exact integers | |
3803 | and the mathematically expected result is representable as an exact integer | |
3804 | within the implementation: | |
3805 | ||
3806 | ||
3807 | @example | |
3808 | ||
3809 | + - * | |
3810 | quotient remainder modulo | |
3811 | max min abs | |
3812 | numerator denominator gcd | |
3813 | lcm floor ceiling | |
3814 | truncate round rationalize | |
3815 | expt | |
3816 | ||
3817 | @end example | |
3818 | ||
3819 | ||
3820 | Implementations are encouraged, but not required, to support | |
3821 | @r{exact} @r{integer}s and @r{exact} @r{rational}s of | |
3822 | practically unlimited size and precision, and to implement the | |
3823 | above procedures and the @samp{/} procedure in | |
3824 | such a way that they always return @r{exact} results when given @r{exact} | |
3825 | arguments. If one of these procedures is unable to deliver an @r{exact} | |
3826 | result when given @r{exact} arguments, then it may either report a | |
3827 | violation of an | |
3828 | implementation restriction or it may silently coerce its result to an | |
3829 | @r{inexact} number. Such a coercion may cause an error later. | |
3830 | ||
3831 | @c %R4%% I moved this stuff here. | |
3832 | @c It seems to me that the only thing that this requires is that | |
3833 | @c implementations that support inexact numbers have to have both | |
3834 | @c exact and inexact representations for the integers 0 through 15. | |
3835 | @c If that's what it's saying, I'd rather say it that way. | |
3836 | @c On the other hand, letting the limit be as small as 15 sounds a | |
3837 | @c tad silly, though I think I understand how that number was arrived at. | |
3838 | @c (Or is 35 the number?) | |
3839 | ||
3840 | @c Implementations are encouraged, but not required, to support \tupe{inexact} | |
3841 | @c numbers. For any implementation that supports \tupe{inexact} numbers, | |
3842 | @c there is a subset of the integers for which there are both \tupe{exact} and | |
3843 | @c \tupe{inexact} representations. This subset must include all non-negative | |
3844 | @c integers up to some limit specified by the implementation. This limit | |
3845 | @c must be 16 or greater. The | |
3846 | @c \ide{exact\coerce{}inexact} and \ide{inexact\coerce{}exact} | |
3847 | @c procedures implement the natural one-to-one correspondence between | |
3848 | @c the \tupe{inexact} and \tupe{exact} integers within this range. | |
3849 | ||
3850 | An implementation may use floating point and other approximate | |
3851 | representation strategies for @r{inexact} numbers. | |
3852 | @c %R4%% The following sentence seemed a bit condescending as well as | |
3853 | @c awkward. It didn't seem to be very enforceable, so I flushed it. | |
3854 | ||
3855 | @c This is not to | |
3856 | @c say that implementors need not use the best known algorithms for | |
3857 | @c \tupe{inexact} computations---only that approximate methods of high | |
3858 | @c quality are allowed. | |
3859 | ||
3860 | This report recommends, but does not require, that the IEEE 32-bit | |
3861 | and 64-bit floating point standards be followed by implementations that use | |
3862 | flonum representations, and that implementations using | |
3863 | other representations should match or exceed the precision achievable | |
3864 | using these floating point standards [IEEE]. | |
3865 | ||
3866 | In particular, implementations that use flonum representations | |
3867 | must follow these rules: A @r{flonum} result | |
3868 | must be represented with at least as much precision as is used to express any of | |
3869 | the inexact arguments to that operation. It is desirable (but not required) for | |
3870 | potentially inexact operations such as @samp{sqrt}, when applied to @r{exact} | |
3871 | arguments, to produce @r{exact} answers whenever possible (for example the | |
3872 | square root of an @r{exact} 4 ought to be an @r{exact} 2). | |
3873 | If, however, an | |
3874 | @r{exact} number is operated upon so as to produce an @r{inexact} result | |
3875 | (as by @samp{sqrt}), and if the result is represented as a @r{flonum}, then | |
3876 | the most precise @r{flonum} format available must be used; but if the result | |
3877 | is represented in some other way then the representation must have at least as | |
3878 | much precision as the most precise @r{flonum} format available. | |
3879 | ||
3880 | Although Scheme allows a variety of written | |
3881 | @c %R4%% representations of | |
3882 | notations for | |
3883 | numbers, any particular implementation may support only some of them. | |
3884 | @c %R4%% | |
3885 | For example, an implementation in which all numbers are @r{real} | |
3886 | need not support the rectangular and polar notations for complex | |
3887 | numbers. If an implementation encounters an @r{exact} numerical constant that | |
3888 | it cannot represent as an @r{exact} number, then it may either report a | |
3889 | violation of an implementation restriction or it may silently represent the | |
3890 | constant by an @r{inexact} number. | |
3891 | ||
3892 | ||
3893 | @node Syntax of numerical constants, Numerical operations, Implementation restrictions, Numbers | |
3894 | @subsection Syntax of numerical constants | |
3895 | ||
3896 | ||
3897 | ||
3898 | @c @@@@LOSE@@@@ | |
3899 | ||
3900 | @c %R4%% I removed the following paragraph in an attempt to tighten up | |
3901 | @c this subsection. Except for its first sentence, which I moved to | |
3902 | @c the subsection on implementation restrictions, I think its content | |
3903 | @c is implied by the rest of the section. | |
3904 | ||
3905 | @c Although Scheme allows a variety of written representations of numbers, | |
3906 | @c any particular implementation may support only some of them. | |
3907 | @c These syntaxes are intended to be purely notational; any kind of number | |
3908 | @c may be written in any form that the user deems convenient. Of course, | |
3909 | @c writing 1/7 as a limited-precision decimal fraction will not express the | |
3910 | @c number exactly, but this approximate form of expression may be just what | |
3911 | @c the user wants to see. | |
3912 | ||
3913 | The syntax of the written representations for numbers is described formally in | |
3914 | section @ref{Lexical structure}. Note that case is not significant in numerical | |
3915 | constants. | |
3916 | ||
3917 | @c %R4%% See section~\ref{numberformats} for many examples. | |
3918 | ||
3919 | A number may be written in binary, octal, decimal, or | |
3920 | hexadecimal by the use of a radix prefix. The radix prefixes are @samp{#b} (binary), @samp{#o} (octal), @samp{#d} (decimal), and @samp{#x} (hexadecimal). With | |
3921 | @vindex #x | |
3922 | @vindex #d | |
3923 | @vindex #o | |
3924 | @vindex #b | |
3925 | no radix prefix, a number is assumed to be expressed in decimal. | |
3926 | ||
3927 | A | |
3928 | @c %R4%% | |
3929 | @c simple | |
3930 | numerical constant may be specified to be either @r{exact} or | |
3931 | @r{inexact} by a prefix. The prefixes are @samp{#e} | |
3932 | @vindex #e | |
3933 | for @r{exact}, and @samp{#i} for @r{inexact}. An exactness | |
3934 | @vindex #i | |
3935 | prefix may appear before or after any radix prefix that is used. If | |
3936 | the written representation of a number has no exactness prefix, the | |
3937 | constant may be either @r{inexact} or @r{exact}. It is | |
3938 | @r{inexact} if it contains a decimal point, an | |
3939 | exponent, or a ``#'' character in the place of a digit, | |
3940 | otherwise it is @r{exact}. | |
3941 | @c %R4%% With our new syntax, the following sentence is redundant: | |
3942 | ||
3943 | @c The written representation of a | |
3944 | @c compound number, such as a ratio or a complex, is exact if and only if | |
3945 | @c all of its constituents are exact. | |
3946 | ||
3947 | In systems with @r{inexact} numbers | |
3948 | of varying precisions it may be useful to specify | |
3949 | the precision of a constant. For this purpose, numerical constants | |
3950 | may be written with an exponent marker that indicates the | |
3951 | desired precision of the @r{inexact} | |
3952 | representation. The letters @samp{s}, @samp{f}, | |
3953 | @samp{d}, and @samp{l} specify the use of @var{short}, @var{single}, | |
3954 | @var{double}, and @var{long} precision, respectively. (When fewer | |
3955 | than four internal | |
3956 | @c %R4%%\tupe{flonum} | |
3957 | @r{inexact} | |
3958 | representations exist, the four size | |
3959 | specifications are mapped onto those available. For example, an | |
3960 | implementation with two internal representations may map short and | |
3961 | single together and long and double together.) In addition, the | |
3962 | exponent marker @samp{e} specifies the default precision for the | |
3963 | implementation. The default precision has at least as much precision | |
3964 | as @var{double}, but | |
3965 | implementations may wish to allow this default to be set by the user. | |
3966 | ||
3967 | ||
3968 | @example | |
3969 | ||
3970 | 3.14159265358979F0 | |
3971 | @r{Round to single ---} 3.141593 | |
3972 | 0.6L0 | |
3973 | @r{Extend to long ---} .600000000000000 | |
3974 | ||
3975 | @end example | |
3976 | ||
3977 | ||
3978 | ||
3979 | @node Numerical operations, Numerical input and output, Syntax of numerical constants, Numbers | |
3980 | @subsection Numerical operations | |
3981 | ||
3982 | ||
3983 | The reader is referred to section @ref{Entry format} for a summary | |
3984 | of the naming conventions used to specify restrictions on the types of | |
3985 | arguments to numerical routines. | |
3986 | @c %R4%% The following sentence has already been said twice, and the | |
3987 | @c term "exactness-preserving" is no longer defined by the Report. | |
3988 | ||
3989 | @c Remember that | |
3990 | @c an exactness-preserving operation may coerce its result to inexact if the | |
3991 | @c implementation is unable to represent it exactly. | |
3992 | The examples used in this section assume that any numerical constant written | |
3993 | using an @r{exact} notation is indeed represented as an @r{exact} | |
3994 | number. Some examples also assume that certain numerical constants written | |
3995 | using an @r{inexact} notation can be represented without loss of | |
3996 | accuracy; the @r{inexact} constants were chosen so that this is | |
3997 | likely to be true in implementations that use flonums to represent | |
3998 | inexact numbers. | |
3999 | ||
4000 | @ignore todo | |
4001 | Scheme provides the usual set of operations for manipulating | |
4002 | numbers, etc. | |
4003 | @end ignore | |
4004 | ||
4005 | ||
4006 | ||
4007 | @deffn {procedure} number? obj | |
4008 | @deffnx {procedure} complex? obj | |
4009 | @deffnx {procedure} real? obj | |
4010 | @deffnx {procedure} rational? obj | |
4011 | @deffnx {procedure} integer? obj | |
4012 | ||
4013 | These numerical type predicates can be applied to any kind of | |
4014 | argument, including non-numbers. They return @t{#t} if the object is | |
4015 | of the named type, and otherwise they return @t{#f}. | |
4016 | In general, if a type predicate is true of a number then all higher | |
4017 | type predicates are also true of that number. Consequently, if a type | |
4018 | predicate is false of a number, then all lower type predicates are | |
4019 | also false of that number. | |
4020 | @c %R4%% The new section on implementation restrictions subsumes: | |
4021 | @c Not every system | |
4022 | @c supports all of these types; for example, it is entirely possible to have a | |
4023 | @c Scheme system that has only \tupe{integer}s. Nonetheless every implementation | |
4024 | @c of Scheme must have all of these predicates. | |
4025 | ||
4026 | If @var{z} is an inexact complex number, then @samp{(real? @var{z})} is true if | |
4027 | and only if @samp{(zero? (imag-part @var{z}))} is true. If @var{x} is an inexact | |
4028 | real number, then @samp{(integer? @var{x})} is true if and only if | |
4029 | @samp{(= @var{x} (round @var{x}))}. | |
4030 | ||
4031 | ||
4032 | @format | |
4033 | @t{(complex? 3+4i) ==> #t | |
4034 | (complex? 3) ==> #t | |
4035 | (real? 3) ==> #t | |
4036 | (real? -2.5+0.0i) ==> #t | |
4037 | (real? #e1e10) ==> #t | |
4038 | (rational? 6/10) ==> #t | |
4039 | (rational? 6/3) ==> #t | |
4040 | (integer? 3+0i) ==> #t | |
4041 | (integer? 3.0) ==> #t | |
4042 | (integer? 8/4) ==> #t | |
4043 | } | |
4044 | @end format | |
4045 | ||
4046 | ||
4047 | ||
4048 | @quotation | |
4049 | @emph{Note:} | |
4050 | The behavior of these type predicates on @r{inexact} numbers | |
4051 | is unreliable, since any inaccuracy may affect the result. | |
4052 | @end quotation | |
4053 | ||
4054 | ||
4055 | ||
4056 | @quotation | |
4057 | @emph{Note:} | |
4058 | In many implementations the @code{rational?} procedure will be the same | |
4059 | @vindex @w{rational?} | |
4060 | as @code{real?}, and the @code{complex?} procedure will be the same as | |
4061 | @vindex @w{complex?} | |
4062 | @vindex @w{real?} | |
4063 | @code{number?}, but unusual implementations may be able to represent | |
4064 | @vindex @w{number?} | |
4065 | some irrational numbers exactly or may extend the number system to | |
4066 | support some kind of non-complex numbers. | |
4067 | @end quotation | |
4068 | ||
4069 | ||
4070 | @end deffn | |
4071 | ||
4072 | ||
4073 | @deffn {procedure} exact? @var{z} | |
4074 | @deffnx {procedure} inexact? @var{z} | |
4075 | ||
4076 | These numerical predicates provide tests for the exactness of a | |
4077 | quantity. For any Scheme number, precisely one of these predicates | |
4078 | is true. | |
4079 | ||
4080 | @end deffn | |
4081 | ||
4082 | ||
4083 | ||
4084 | @deffn {procedure} = z1 z2 z3 @dots{}, | |
4085 | @deffnx {procedure} < x1 x2 x3 @dots{}, | |
4086 | @deffnx {procedure} > x1 x2 x3 @dots{}, | |
4087 | @deffnx {procedure} <= x1 x2 x3 @dots{}, | |
4088 | @deffnx {procedure} >= x1 x2 x3 @dots{}, | |
4089 | ||
4090 | @c - Some implementations allow these procedures to take many arguments, to | |
4091 | @c - facilitate range checks. | |
4092 | These procedures return @t{#t} if their arguments are (respectively): | |
4093 | equal, monotonically increasing, monotonically decreasing, | |
4094 | monotonically nondecreasing, or monotonically nonincreasing. | |
4095 | ||
4096 | These predicates are required to be transitive. | |
4097 | ||
4098 | ||
4099 | @quotation | |
4100 | @emph{Note:} | |
4101 | The traditional implementations of these predicates in Lisp-like | |
4102 | languages are not transitive. | |
4103 | @end quotation | |
4104 | ||
4105 | ||
4106 | ||
4107 | @quotation | |
4108 | @emph{Note:} | |
4109 | While it is not an error to compare @r{inexact} numbers using these | |
4110 | predicates, the results may be unreliable because a small inaccuracy | |
4111 | may affect the result; this is especially true of @code{=} and @code{zero?}. | |
4112 | @vindex @w{zero?} | |
4113 | @vindex @w{=} | |
4114 | When in doubt, consult a numerical analyst. | |
4115 | @end quotation | |
4116 | ||
4117 | ||
4118 | @end deffn | |
4119 | ||
4120 | ||
4121 | @deffn {library procedure} zero? @var{z} | |
4122 | @deffnx {library procedure} positive? @var{x} | |
4123 | @deffnx {library procedure} negative? @var{x} | |
4124 | @deffnx {library procedure} odd? @var{n} | |
4125 | @deffnx {library procedure} even? @var{n} | |
4126 | ||
4127 | These numerical predicates test a number for a particular property, | |
4128 | returning @t{#t} or @t{#f}. See note above. | |
4129 | ||
4130 | @end deffn | |
4131 | ||
4132 | ||
4133 | @deffn {library procedure} max x1 x2 @dots{}, | |
4134 | @deffnx {library procedure} min x1 x2 @dots{}, | |
4135 | ||
4136 | These procedures return the maximum or minimum of their arguments. | |
4137 | ||
4138 | ||
4139 | @format | |
4140 | @t{(max 3 4) ==> 4 ; exact | |
4141 | (max 3.9 4) ==> 4.0 ; inexact | |
4142 | } | |
4143 | @end format | |
4144 | ||
4145 | ||
4146 | ||
4147 | @quotation | |
4148 | @emph{Note:} | |
4149 | If any argument is inexact, then the result will also be inexact (unless | |
4150 | the procedure can prove that the inaccuracy is not large enough to affect the | |
4151 | result, which is possible only in unusual implementations). If @samp{min} or | |
4152 | @samp{max} is used to compare numbers of mixed exactness, and the numerical | |
4153 | value of the result cannot be represented as an inexact number without loss of | |
4154 | accuracy, then the procedure may report a violation of an implementation | |
4155 | restriction. | |
4156 | @end quotation | |
4157 | ||
4158 | ||
4159 | @end deffn | |
4160 | ||
4161 | ||
4162 | ||
4163 | @deffn {procedure} + z1 @dots{}, | |
4164 | @deffnx {procedure} * z1 @dots{}, | |
4165 | ||
4166 | These procedures return the sum or product of their arguments. | |
4167 | @c - These procedures are exactness preserving. | |
4168 | ||
4169 | ||
4170 | @format | |
4171 | @t{(+ 3 4) ==> 7 | |
4172 | (+ 3) ==> 3 | |
4173 | (+) ==> 0 | |
4174 | (* 4) ==> 4 | |
4175 | (*) ==> 1 | |
4176 | } | |
4177 | @end format | |
4178 | ||
4179 | ||
4180 | @end deffn | |
4181 | ||
4182 | ||
4183 | ||
4184 | @deffn {procedure} - z1 z2 | |
4185 | @deffnx {procedure} - @var{z} | |
4186 | @deffnx {optional procedure} - z1 z2 @dots{}, | |
4187 | @deffnx {procedure} / z1 z2 | |
4188 | @deffnx {procedure} / @var{z} | |
4189 | @deffnx {optional procedure} / z1 z2 @dots{}, | |
4190 | ||
4191 | With two or more arguments, these procedures return the difference or | |
4192 | quotient of their arguments, associating to the left. With one argument, | |
4193 | however, they return the additive or multiplicative inverse of their argument. | |
4194 | @c - These procedures are exactness preserving, except that division may | |
4195 | @c - coerce its result to inexact in implementations that do not support | |
4196 | @c - \tupe{ratnum}s. | |
4197 | ||
4198 | ||
4199 | @format | |
4200 | @t{(- 3 4) ==> -1 | |
4201 | (- 3 4 5) ==> -6 | |
4202 | (- 3) ==> -3 | |
4203 | (/ 3 4 5) ==> 3/20 | |
4204 | (/ 3) ==> 1/3 | |
4205 | } | |
4206 | @end format | |
4207 | ||
4208 | ||
4209 | @end deffn | |
4210 | ||
4211 | ||
4212 | ||
4213 | @deffn {library procedure} abs x | |
4214 | ||
4215 | @samp{Abs} returns the absolute value of its argument. | |
4216 | @c - {\cf Abs} is exactness preserving when its argument is real. | |
4217 | ||
4218 | @format | |
4219 | @t{(abs -7) ==> 7 | |
4220 | } | |
4221 | @end format | |
4222 | ||
4223 | @end deffn | |
4224 | ||
4225 | ||
4226 | ||
4227 | @deffn {procedure} quotient n1 n2 | |
4228 | @deffnx {procedure} remainder n1 n2 | |
4229 | @deffnx {procedure} modulo n1 n2 | |
4230 | ||
4231 | These procedures implement number-theoretic (integer) | |
4232 | division. @var{n2} should be non-zero. All three procedures | |
4233 | return integers. If @var{n1}/@var{n2} is an integer: | |
4234 | ||
4235 | @format | |
4236 | @t{ (quotient @var{n1} @var{n2}) ==> @var{n1}/@var{n2} | |
4237 | (remainder @var{n1} @var{n2}) ==> 0 | |
4238 | (modulo @var{n1} @var{n2}) ==> 0 | |
4239 | } | |
4240 | @end format | |
4241 | ||
4242 | If @var{n1}/@var{n2} is not an integer: | |
4243 | ||
4244 | @format | |
4245 | @t{ (quotient @var{n1} @var{n2}) ==> @var{n_q} | |
4246 | (remainder @var{n1} @var{n2}) ==> @var{n_r} | |
4247 | (modulo @var{n1} @var{n2}) ==> @var{n_m} | |
4248 | } | |
4249 | @end format | |
4250 | ||
4251 | where @var{n_q} is @var{n1}/@var{n2} rounded towards zero, | |
4252 | 0 < |@var{n_r}| < |@var{n2}|, 0 < |@var{n_m}| < |@var{n2}|, | |
4253 | @var{n_r} and @var{n_m} differ from @var{n1} by a multiple of @var{n2}, | |
4254 | @var{n_r} has the same sign as @var{n1}, and | |
4255 | @var{n_m} has the same sign as @var{n2}. | |
4256 | ||
4257 | From this we can conclude that for integers @var{n1} and @var{n2} with | |
4258 | @var{n2} not equal to 0, | |
4259 | ||
4260 | @format | |
4261 | @t{ (= @var{n1} (+ (* @var{n2} (quotient @var{n1} @var{n2})) | |
4262 | (remainder @var{n1} @var{n2}))) | |
4263 | ==> #t | |
4264 | } | |
4265 | @end format | |
4266 | ||
4267 | provided all numbers involved in that computation are exact. | |
4268 | ||
4269 | ||
4270 | @format | |
4271 | @t{(modulo 13 4) ==> 1 | |
4272 | (remainder 13 4) ==> 1 | |
4273 | ||
4274 | (modulo -13 4) ==> 3 | |
4275 | (remainder -13 4) ==> -1 | |
4276 | ||
4277 | (modulo 13 -4) ==> -3 | |
4278 | (remainder 13 -4) ==> 1 | |
4279 | ||
4280 | (modulo -13 -4) ==> -1 | |
4281 | (remainder -13 -4) ==> -1 | |
4282 | ||
4283 | (remainder -13 -4.0) ==> -1.0 ; inexact | |
4284 | } | |
4285 | @end format | |
4286 | ||
4287 | @end deffn | |
4288 | ||
4289 | ||
4290 | @deffn {library procedure} gcd n1 @dots{}, | |
4291 | @deffnx {library procedure} lcm n1 @dots{}, | |
4292 | ||
4293 | These procedures return the greatest common divisor or least common | |
4294 | multiple of their arguments. The result is always non-negative. | |
4295 | @c - These procedures are exactness preserving. | |
4296 | ||
4297 | @c %R4%% I added the inexact example. | |
4298 | ||
4299 | @format | |
4300 | @t{(gcd 32 -36) ==> 4 | |
4301 | (gcd) ==> 0 | |
4302 | (lcm 32 -36) ==> 288 | |
4303 | (lcm 32.0 -36) ==> 288.0 ; inexact | |
4304 | (lcm) ==> 1 | |
4305 | } | |
4306 | @end format | |
4307 | ||
4308 | ||
4309 | @end deffn | |
4310 | ||
4311 | ||
4312 | ||
4313 | @deffn {procedure} numerator @var{q} | |
4314 | @deffnx {procedure} denominator @var{q} | |
4315 | ||
4316 | These procedures return the numerator or denominator of their | |
4317 | argument; the result is computed as if the argument was represented as | |
4318 | a fraction in lowest terms. The denominator is always positive. The | |
4319 | denominator of 0 is defined to be 1. | |
4320 | @c - The remarks about denominators are new. | |
4321 | @c - Clearly, they are exactness-preserving procedures. | |
4322 | ||
4323 | @ignore todo | |
4324 | More description and examples needed. | |
4325 | @end ignore | |
4326 | ||
4327 | ||
4328 | @format | |
4329 | @t{(numerator (/ 6 4)) ==> 3 | |
4330 | (denominator (/ 6 4)) ==> 2 | |
4331 | (denominator | |
4332 | (exact->inexact (/ 6 4))) ==> 2.0 | |
4333 | } | |
4334 | @end format | |
4335 | ||
4336 | ||
4337 | @end deffn | |
4338 | ||
4339 | ||
4340 | ||
4341 | @deffn {procedure} floor x | |
4342 | @deffnx {procedure} ceiling x | |
4343 | @deffnx {procedure} truncate x | |
4344 | @deffnx {procedure} round x | |
4345 | ||
4346 | ||
4347 | These procedures return integers. | |
4348 | @samp{Floor} returns the largest integer not larger than @var{x}. | |
4349 | @samp{Ceiling} returns the smallest integer not smaller than @var{x}. | |
4350 | @samp{Truncate} returns the integer closest to @var{x} whose absolute | |
4351 | value is not larger than the absolute value of @var{x}. @samp{Round} returns the | |
4352 | closest integer to @var{x}, rounding to even when @var{x} is halfway between two | |
4353 | integers. | |
4354 | ||
4355 | ||
4356 | @quotation | |
4357 | @emph{Rationale:} | |
4358 | @samp{Round} rounds to even for consistency with the default rounding | |
4359 | mode specified by the IEEE floating point standard. | |
4360 | @end quotation | |
4361 | ||
4362 | ||
4363 | ||
4364 | @quotation | |
4365 | @emph{Note:} | |
4366 | If the argument to one of these procedures is inexact, then the result | |
4367 | will also be inexact. If an exact value is needed, the | |
4368 | result should be passed to the @samp{inexact->exact} procedure. | |
4369 | @end quotation | |
4370 | ||
4371 | ||
4372 | ||
4373 | @format | |
4374 | @t{(floor -4.3) ==> -5.0 | |
4375 | (ceiling -4.3) ==> -4.0 | |
4376 | (truncate -4.3) ==> -4.0 | |
4377 | (round -4.3) ==> -4.0 | |
4378 | ||
4379 | (floor 3.5) ==> 3.0 | |
4380 | (ceiling 3.5) ==> 4.0 | |
4381 | (truncate 3.5) ==> 3.0 | |
4382 | (round 3.5) ==> 4.0 ; inexact | |
4383 | ||
4384 | (round 7/2) ==> 4 ; exact | |
4385 | (round 7) ==> 7 | |
4386 | } | |
4387 | @end format | |
4388 | ||
4389 | ||
4390 | @end deffn | |
4391 | ||
4392 | ||
4393 | @deffn {library procedure} rationalize x y | |
4394 | @c - \proto{rationalize}{ x}{procedure} | |
4395 | ||
4396 | ||
4397 | @samp{Rationalize} returns the @emph{simplest} rational number | |
4398 | differing from @var{x} by no more than @var{y}. A rational number r_1 is | |
4399 | @emph{simpler} than another rational number | |
4400 | @cindex @w{simplest rational} | |
4401 | r_2 if r_1 = p_1/q_1 and r_2 = p_2/q_2 (in lowest terms) and |p_1|<= |p_2| and |q_1| <= |q_2|. Thus 3/5 is simpler than 4/7. | |
4402 | Although not all rationals are comparable in this ordering (consider 2/7 | |
4403 | and 3/5) any interval contains a rational number that is simpler than | |
4404 | every other rational number in that interval (the simpler 2/5 lies | |
4405 | between 2/7 and 3/5). Note that 0 = 0/1 is the simplest rational of | |
4406 | all. | |
4407 | ||
4408 | ||
4409 | @format | |
4410 | @t{(rationalize | |
4411 | (inexact->exact .3) 1/10) ==> 1/3 ; exact | |
4412 | (rationalize .3 1/10) ==> #i1/3 ; inexact | |
4413 | } | |
4414 | @end format | |
4415 | ||
4416 | ||
4417 | @end deffn | |
4418 | ||
4419 | ||
4420 | @deffn {procedure} exp @var{z} | |
4421 | @deffnx {procedure} log @var{z} | |
4422 | @deffnx {procedure} sin @var{z} | |
4423 | @deffnx {procedure} cos @var{z} | |
4424 | @deffnx {procedure} tan @var{z} | |
4425 | @deffnx {procedure} asin @var{z} | |
4426 | @deffnx {procedure} acos @var{z} | |
4427 | @deffnx {procedure} atan @var{z} | |
4428 | @deffnx {procedure} atan @var{y} @var{x} | |
4429 | ||
4430 | These procedures are part of every implementation that supports | |
4431 | @c %R4%% | |
4432 | general | |
4433 | real numbers; they compute the usual transcendental functions. @samp{Log} | |
4434 | computes the natural logarithm of @var{z} (not the base ten logarithm). | |
4435 | @samp{Asin}, @samp{acos}, and @samp{atan} compute arcsine (sin^-1), | |
4436 | arccosine (cos^-1), and arctangent (tan^-1), respectively. | |
4437 | The two-argument variant of @samp{atan} computes @t{(angle | |
4438 | (make-rectangular @var{x} @var{y}))} (see below), even in implementations | |
4439 | that don't support general complex numbers. | |
4440 | ||
4441 | In general, the mathematical functions log, arcsine, arccosine, and | |
4442 | arctangent are multiply defined. | |
4443 | The value of log z is defined to be the one whose imaginary | |
4444 | part lies in the range from -pi (exclusive) to pi (inclusive). | |
4445 | log 0 is undefined. | |
4446 | With log defined this way, the values of sin^-1 z, cos^-1 z, | |
4447 | and tan^-1 z are according to the following formulae: | |
4448 | ||
4449 | ||
4450 | @center sin^-1 z = -i log (i z + sqrt1 - z^2) | |
4451 | ||
4452 | ||
4453 | ||
4454 | @center cos^-1 z = pi / 2 - sin^-1 z | |
4455 | ||
4456 | ||
4457 | ||
4458 | @center tan^-1 z = (log (1 + i z) - log (1 - i z)) / (2 i) | |
4459 | ||
4460 | ||
4461 | The above specification follows [CLtL], which in turn | |
4462 | cites [Penfield81]; refer to these sources for more detailed | |
4463 | discussion of branch cuts, boundary conditions, and implementation of | |
4464 | these functions. When it is possible these procedures produce a real | |
4465 | result from a real argument. | |
4466 | ||
4467 | @c %R4%% | |
4468 | ||
4469 | @ignore todo | |
4470 | The cited references are likely to change their branch cuts | |
4471 | soon to allow for the possibility of distinct positive and negative | |
4472 | zeroes, as in IEEE floating point. We may not want to follow those | |
4473 | changes, since we may want a complex number with zero imaginary part | |
4474 | (whether positive or negative zero) to be treated as a real. I don't | |
4475 | think there are any better standards for complex arithmetic than the | |
4476 | ones cited, so we're really on our own here. | |
4477 | @end ignore | |
4478 | ||
4479 | ||
4480 | @end deffn | |
4481 | ||
4482 | ||
4483 | ||
4484 | @deffn {procedure} sqrt @var{z} | |
4485 | ||
4486 | Returns the principal square root of @var{z}. The result will have | |
4487 | either positive real part, or zero real part and non-negative imaginary | |
4488 | part. | |
4489 | @end deffn | |
4490 | ||
4491 | ||
4492 | ||
4493 | @deffn {procedure} expt z1 z2 | |
4494 | ||
4495 | Returns @var{z1} raised to the power @var{z2}. For z_1 ~= 0 | |
4496 | ||
4497 | ||
4498 | @center z_1^z_2 = e^z_2 log z_1 | |
4499 | ||
4500 | 0^z is 1 if z = 0 and 0 otherwise. | |
4501 | @end deffn | |
4502 | ||
4503 | @c - \begin{entry}{%- | |
4504 | @c - \proto{approximate}{ z x}{procedure}} | |
4505 | @c - | |
4506 | @c - Returns an approximation to \vr{z} in a representation whose precision is | |
4507 | @c - the same as that | |
4508 | @c - of the representation of \vr{x}, which must be an inexact number. The | |
4509 | @c - result is always inexact. | |
4510 | @c - | |
4511 | @c - \begin{scheme} | |
4512 | @c - (approximate 3.1415926535 1F10) | |
4513 | @c - \ev 3.14159F0 | |
4514 | @c - (approximate 3.1415926535 \#I65535) | |
4515 | @c - \ev \#I3 | |
4516 | @c - (approximate 3.14F0 1L8) | |
4517 | @c - \ev 3.14L0 | |
4518 | @c - (approximate 3.1415926535F0 1L8) | |
4519 | @c - \ev 3.14159L0 | |
4520 | @c - \end{scheme} | |
4521 | @c - \end{entry} | |
4522 | ||
4523 | ||
4524 | ||
4525 | ||
4526 | @deffn {procedure} make-rectangular x1 x2 | |
4527 | @deffnx {procedure} make-polar x3 x4 | |
4528 | @deffnx {procedure} real-part @var{z} | |
4529 | @deffnx {procedure} imag-part @var{z} | |
4530 | @deffnx {procedure} magnitude @var{z} | |
4531 | @deffnx {procedure} angle @var{z} | |
4532 | ||
4533 | These procedures are part of every implementation that supports | |
4534 | @c %R4%% | |
4535 | general | |
4536 | complex numbers. Suppose @var{x1}, @var{x2}, @var{x3}, and @var{x4} are | |
4537 | real numbers and @var{z} is a complex number such that | |
4538 | ||
4539 | ||
4540 | @center @var{z} = @var{x1} + @var{x2}@w{i} = @var{x3} . e^@w{i} @var{x4} | |
4541 | ||
4542 | Then | |
4543 | ||
4544 | @format | |
4545 | @t{(make-rectangular @var{x1} @var{x2}) ==> @var{z} | |
4546 | (make-polar @var{x3} @var{x4}) ==> @var{z} | |
4547 | (real-part @var{z}) ==> @var{x1} | |
4548 | (imag-part @var{z}) ==> @var{x2} | |
4549 | (magnitude @var{z}) ==> |@var{x3}| | |
4550 | (angle @var{z}) ==> x_angle | |
4551 | } | |
4552 | @end format | |
4553 | ||
4554 | where -pi < x_angle <= pi with x_angle = @var{x4} + 2pi n | |
4555 | for some integer n. | |
4556 | ||
4557 | ||
4558 | @quotation | |
4559 | @emph{Rationale:} | |
4560 | @samp{Magnitude} is the same as @code{abs} for a real argument, | |
4561 | @vindex @w{abs} | |
4562 | but @samp{abs} must be present in all implementations, whereas | |
4563 | @samp{magnitude} need only be present in implementations that support | |
4564 | general complex numbers. | |
4565 | @end quotation | |
4566 | ||
4567 | ||
4568 | @end deffn | |
4569 | ||
4570 | ||
4571 | ||
4572 | @deffn {procedure} exact->inexact @var{z} | |
4573 | @deffnx {procedure} inexact->exact @var{z} | |
4574 | ||
4575 | @samp{Exact->inexact} returns an @r{inexact} representation of @var{z}. | |
4576 | The value returned is the | |
4577 | @r{inexact} number that is numerically closest to the argument. | |
4578 | @c %R4%%For | |
4579 | @c \tupe{exact} arguments which have no reasonably close \tupe{inexact} equivalent, | |
4580 | @c it is permissible to signal an error. | |
4581 | If an @r{exact} argument has no reasonably close @r{inexact} equivalent, | |
4582 | then a violation of an implementation restriction may be reported. | |
4583 | ||
4584 | @samp{Inexact->exact} returns an @r{exact} representation of | |
4585 | @var{z}. The value returned is the @r{exact} number that is numerically | |
4586 | closest to the argument. | |
4587 | @c %R4%% For \tupe{inexact} arguments which have no | |
4588 | @c reasonably close \tupe{exact} equivalent, it is permissible to signal | |
4589 | @c an error. | |
4590 | If an @r{inexact} argument has no reasonably close @r{exact} equivalent, | |
4591 | then a violation of an implementation restriction may be reported. | |
4592 | ||
4593 | @c %R%% I moved this to the section on implementation restrictions. | |
4594 | @c For any implementation that supports \tupe{inexact} quantities, | |
4595 | @c there is a subset of the integers for which there are both \tupe{exact} and | |
4596 | @c \tupe{inexact} representations. This subset must include the non-negative | |
4597 | @c integers up to a limit specified by the implementation. The limit | |
4598 | @c must be big enough to represent all digits in reasonable radices, and | |
4599 | @c may correspond to some natural word size for the implementation. For | |
4600 | @c such integers, these procedures implement the natural one-to-one | |
4601 | @c correspondence between the representations. | |
4602 | ||
4603 | These procedures implement the natural one-to-one correspondence between | |
4604 | @r{exact} and @r{inexact} integers throughout an | |
4605 | implementation-dependent range. See section @ref{Implementation restrictions}. | |
4606 | ||
4607 | @end deffn | |
4608 | ||
4609 | @sp 3 | |
4610 | ||
4611 | @node Numerical input and output, , Numerical operations, Numbers | |
4612 | @subsection Numerical input and output | |
4613 | ||
4614 | ||
4615 | ||
4616 | @deffn {procedure} number->string z | |
4617 | @deffnx {procedure} number->string z radix | |
4618 | ||
4619 | @var{Radix} must be an exact integer, either 2, 8, 10, or 16. If omitted, | |
4620 | @var{radix} defaults to 10. | |
4621 | The procedure @samp{number->string} takes a | |
4622 | number and a radix and returns as a string an external representation of | |
4623 | the given number in the given radix such that | |
4624 | ||
4625 | @format | |
4626 | @t{(let ((number @var{number}) | |
4627 | (radix @var{radix})) | |
4628 | (eqv? number | |
4629 | (string->number (number->string number | |
4630 | radix) | |
4631 | radix))) | |
4632 | } | |
4633 | @end format | |
4634 | ||
4635 | is true. It is an error if no possible result makes this expression true. | |
4636 | ||
4637 | If @var{z} is inexact, the radix is 10, and the above expression | |
4638 | can be satisfied by a result that contains a decimal point, | |
4639 | then the result contains a decimal point and is expressed using the | |
4640 | minimum number of digits (exclusive of exponent and trailing | |
4641 | zeroes) needed to make the above expression | |
4642 | true [howtoprint], [howtoread]; | |
4643 | otherwise the format of the result is unspecified. | |
4644 | ||
4645 | The result returned by @samp{number->string} | |
4646 | never contains an explicit radix prefix. | |
4647 | ||
4648 | ||
4649 | @quotation | |
4650 | @emph{Note:} | |
4651 | The error case can occur only when @var{z} is not a complex number | |
4652 | or is a complex number with a non-rational real or imaginary part. | |
4653 | @end quotation | |
4654 | ||
4655 | ||
4656 | ||
4657 | @quotation | |
4658 | @emph{Rationale:} | |
4659 | If @var{z} is an inexact number represented using flonums, and | |
4660 | the radix is 10, then the above expression is normally satisfied by | |
4661 | a result containing a decimal point. The unspecified case | |
4662 | allows for infinities, NaNs, and non-flonum representations. | |
4663 | @end quotation | |
4664 | ||
4665 | ||
4666 | @end deffn | |
4667 | ||
4668 | ||
4669 | ||
4670 | @deffn {procedure} string->number string | |
4671 | @deffnx {procedure} string->number string radix | |
4672 | ||
4673 | @c %R4%% I didn't include the (string->number string radix exactness) | |
4674 | @c case, since I haven't heard any resolution of the coding to be used | |
4675 | @c for the third argument. | |
4676 | ||
4677 | Returns a number of the maximally precise representation expressed by the | |
4678 | given @var{string}. @var{Radix} must be an exact integer, either 2, 8, 10, | |
4679 | or 16. If supplied, @var{radix} is a default radix that may be overridden | |
4680 | by an explicit radix prefix in @var{string} (e.g. @t{"#o177"}). If @var{radix} | |
4681 | is not supplied, then the default radix is 10. If @var{string} is not | |
4682 | a syntactically valid notation for a number, then @samp{string->number} | |
4683 | returns @t{#f}. | |
4684 | ||
4685 | ||
4686 | @format | |
4687 | @t{(string->number "100") ==> 100 | |
4688 | (string->number "100" 16) ==> 256 | |
4689 | (string->number "1e2") ==> 100.0 | |
4690 | (string->number "15##") ==> 1500.0 | |
4691 | } | |
4692 | @end format | |
4693 | ||
4694 | ||
4695 | ||
4696 | @quotation | |
4697 | @emph{Note:} | |
4698 | The domain of @samp{string->number} may be restricted by implementations | |
4699 | in the following ways. @samp{String->number} is permitted to return | |
4700 | @t{#f} whenever @var{string} contains an explicit radix prefix. | |
4701 | If all numbers supported by an implementation are real, then | |
4702 | @samp{string->number} is permitted to return @t{#f} whenever | |
4703 | @var{string} uses the polar or rectangular notations for complex | |
4704 | numbers. If all numbers are integers, then | |
4705 | @samp{string->number} may return @t{#f} whenever | |
4706 | the fractional notation is used. If all numbers are exact, then | |
4707 | @samp{string->number} may return @t{#f} whenever | |
4708 | an exponent marker or explicit exactness prefix is used, or if | |
4709 | a @t{#} appears in place of a digit. If all inexact | |
4710 | numbers are integers, then | |
4711 | @samp{string->number} may return @t{#f} whenever | |
4712 | a decimal point is used. | |
4713 | @end quotation | |
4714 | ||
4715 | ||
4716 | @end deffn | |
4717 | ||
4718 | @node Other data types, Control features, Numbers, Standard procedures | |
4719 | @section Other data types | |
4720 | ||
4721 | @menu | |
4722 | * Booleans:: | |
4723 | * Pairs and lists:: | |
4724 | * Symbols:: | |
4725 | * Characters:: | |
4726 | * Strings:: | |
4727 | * Vectors:: | |
4728 | @end menu | |
4729 | ||
4730 | ||
4731 | This section describes operations on some of Scheme's non-numeric data types: | |
4732 | booleans, pairs, lists, symbols, characters, strings and vectors. | |
4733 | ||
4734 | @node Booleans, Pairs and lists, Other data types, Other data types | |
4735 | @subsection Booleans | |
4736 | ||
4737 | ||
4738 | ||
4739 | The standard boolean objects for true and false are written as | |
4740 | @t{#t} and @t{#f}. What really | |
4741 | @vindex #f | |
4742 | @vindex #t | |
4743 | matters, though, are the objects that the Scheme conditional expressions | |
4744 | (@samp{if}, @samp{cond}, @samp{and}, @samp{or}, @samp{do}) treat as | |
4745 | true or false. The phrase ``a true value'' | |
4746 | @cindex @w{false} | |
4747 | @cindex @w{true} | |
4748 | (or sometimes just ``true'') means any object treated as true by the | |
4749 | conditional expressions, and the phrase ``a false value'' (or | |
4750 | @cindex @w{false} | |
4751 | ``false'') means any object treated as false by the conditional expressions. | |
4752 | ||
4753 | Of all the standard Scheme values, only @t{#f} | |
4754 | @c is guaranteed to count | |
4755 | counts as false in conditional expressions. | |
4756 | @c It is not | |
4757 | @c specified whether the empty list\index{empty list} counts as false | |
4758 | @c or as true in conditional expressions. | |
4759 | Except for @t{#f}, | |
4760 | @c and possibly the empty list, | |
4761 | all standard Scheme values, including @t{#t}, | |
4762 | pairs, the empty list, symbols, numbers, strings, vectors, and procedures, | |
4763 | count as true. | |
4764 | ||
4765 | @c \begin{note} | |
4766 | @c In some implementations the empty list counts as false, contrary | |
4767 | @c to the above. | |
4768 | @c Nonetheless a few examples in this report assume that the | |
4769 | @c empty list counts as true, as in \cite{IEEEScheme}. | |
4770 | @c \end{note} | |
4771 | ||
4772 | @c \begin{rationale} | |
4773 | @c For historical reasons some implementations regard \schfalse{} and the | |
4774 | @c empty list as the same object. These implementations therefore cannot | |
4775 | @c make the empty list count as true in conditional expressions. | |
4776 | @c \end{rationale} | |
4777 | ||
4778 | ||
4779 | @quotation | |
4780 | @emph{Note:} | |
4781 | Programmers accustomed to other dialects of Lisp should be aware that | |
4782 | Scheme distinguishes both @t{#f} and the empty list | |
4783 | @cindex @w{empty list} | |
4784 | from the symbol @code{nil}. | |
4785 | @vindex @w{nil} | |
4786 | @end quotation | |
4787 | ||
4788 | ||
4789 | Boolean constants evaluate to themselves, so they do not need to be quoted | |
4790 | in programs. | |
4791 | ||
4792 | ||
4793 | @example | |
4794 | ||
4795 | #t ==> #t | |
4796 | #f ==> #f | |
4797 | '#f ==> #f | |
4798 | ||
4799 | @end example | |
4800 | ||
4801 | ||
4802 | ||
4803 | ||
4804 | @deffn {library procedure} not obj | |
4805 | ||
4806 | @samp{Not} returns @t{#t} if @var{obj} is false, and returns | |
4807 | @t{#f} otherwise. | |
4808 | ||
4809 | ||
4810 | @format | |
4811 | @t{(not #t) ==> #f | |
4812 | (not 3) ==> #f | |
4813 | (not (list 3)) ==> #f | |
4814 | (not #f) ==> #t | |
4815 | (not '()) ==> #f | |
4816 | (not (list)) ==> #f | |
4817 | (not 'nil) ==> #f | |
4818 | } | |
4819 | @end format | |
4820 | ||
4821 | ||
4822 | @end deffn | |
4823 | ||
4824 | ||
4825 | ||
4826 | @deffn {library procedure} boolean? obj | |
4827 | ||
4828 | @samp{Boolean?} returns @t{#t} if @var{obj} is either @t{#t} or | |
4829 | @t{#f} and returns @t{#f} otherwise. | |
4830 | ||
4831 | ||
4832 | @format | |
4833 | @t{(boolean? #f) ==> #t | |
4834 | (boolean? 0) ==> #f | |
4835 | (boolean? '()) ==> #f | |
4836 | } | |
4837 | @end format | |
4838 | ||
4839 | ||
4840 | @end deffn | |
4841 | ||
4842 | ||
4843 | @node Pairs and lists, Symbols, Booleans, Other data types | |
4844 | @subsection Pairs and lists | |
4845 | ||
4846 | ||
4847 | ||
4848 | A @dfn{pair} (sometimes called a @dfn{dotted pair}) is a | |
4849 | @cindex @w{dotted pair} | |
4850 | @cindex @w{pair} | |
4851 | record structure with two fields called the car and cdr fields (for | |
4852 | historical reasons). Pairs are created by the procedure @samp{cons}. | |
4853 | The car and cdr fields are accessed by the procedures @samp{car} and | |
4854 | @samp{cdr}. The car and cdr fields are assigned by the procedures | |
4855 | @samp{set-car!} and @samp{set-cdr!}. | |
4856 | ||
4857 | Pairs are used primarily to represent lists. A list can | |
4858 | be defined recursively as either the empty list or a pair whose | |
4859 | @cindex @w{empty list} | |
4860 | cdr is a list. More precisely, the set of lists is defined as the smallest | |
4861 | set @var{X} such that | |
4862 | ||
4863 | ||
4864 | ||
4865 | @itemize @bullet | |
4866 | ||
4867 | @item | |
4868 | The empty list is in @var{X}. | |
4869 | @item | |
4870 | If @var{list} is in @var{X}, then any pair whose cdr field contains | |
4871 | @var{list} is also in @var{X}. | |
4872 | ||
4873 | @end itemize | |
4874 | ||
4875 | ||
4876 | The objects in the car fields of successive pairs of a list are the | |
4877 | elements of the list. For example, a two-element list is a pair whose car | |
4878 | is the first element and whose cdr is a pair whose car is the second element | |
4879 | and whose cdr is the empty list. The length of a list is the number of | |
4880 | elements, which is the same as the number of pairs. | |
4881 | ||
4882 | The empty list is a special object of its own type | |
4883 | @cindex @w{empty list} | |
4884 | (it is not a pair); it has no elements and its length is zero. | |
4885 | ||
4886 | ||
4887 | @quotation | |
4888 | @emph{Note:} | |
4889 | The above definitions imply that all lists have finite length and are | |
4890 | terminated by the empty list. | |
4891 | @end quotation | |
4892 | ||
4893 | ||
4894 | The most general notation (external representation) for Scheme pairs is | |
4895 | the ``dotted'' notation @w{@samp{(@var{c1} .@: @var{c2})}} where | |
4896 | @var{c1} is the value of the car field and @var{c2} is the value of the | |
4897 | cdr field. For example @samp{(4 .@: 5)} is a pair whose car is 4 and whose | |
4898 | cdr is 5. Note that @samp{(4 .@: 5)} is the external representation of a | |
4899 | pair, not an expression that evaluates to a pair. | |
4900 | ||
4901 | A more streamlined notation can be used for lists: the elements of the | |
4902 | list are simply enclosed in parentheses and separated by spaces. The | |
4903 | empty list is written @t{()} . For example, | |
4904 | @cindex @w{empty list} | |
4905 | ||
4906 | ||
4907 | @example | |
4908 | ||
4909 | (a b c d e) | |
4910 | ||
4911 | @end example | |
4912 | ||
4913 | ||
4914 | and | |
4915 | ||
4916 | ||
4917 | @example | |
4918 | ||
4919 | (a . (b . (c . (d . (e . ()))))) | |
4920 | ||
4921 | @end example | |
4922 | ||
4923 | ||
4924 | are equivalent notations for a list of symbols. | |
4925 | ||
4926 | A chain of pairs not ending in the empty list is called an | |
4927 | @dfn{improper list}. Note that an improper list is not a list. | |
4928 | @cindex @w{improper list} | |
4929 | The list and dotted notations can be combined to represent | |
4930 | improper lists: | |
4931 | ||
4932 | ||
4933 | @example | |
4934 | ||
4935 | (a b c . d) | |
4936 | ||
4937 | @end example | |
4938 | ||
4939 | ||
4940 | is equivalent to | |
4941 | ||
4942 | ||
4943 | @example | |
4944 | ||
4945 | (a . (b . (c . d))) | |
4946 | ||
4947 | @end example | |
4948 | ||
4949 | ||
4950 | Whether a given pair is a list depends upon what is stored in the cdr | |
4951 | field. When the @code{set-cdr!} procedure is used, an object can be a | |
4952 | @vindex @w{set-cdr!} | |
4953 | list one moment and not the next: | |
4954 | ||
4955 | ||
4956 | @example | |
4957 | ||
4958 | (define x (list 'a 'b 'c)) | |
4959 | (define y x) | |
4960 | y ==> (a b c) | |
4961 | (list? y) ==> #t | |
4962 | (set-cdr! x 4) ==> @emph{unspecified} | |
4963 | x ==> (a . 4) | |
4964 | (eqv? x y) ==> #t | |
4965 | y ==> (a . 4) | |
4966 | (list? y) ==> #f | |
4967 | (set-cdr! x x) ==> @emph{unspecified} | |
4968 | (list? x) ==> #f | |
4969 | ||
4970 | @end example | |
4971 | ||
4972 | ||
4973 | @c It is often convenient to speak of a homogeneous list of objects | |
4974 | @c of some particular data type, as for example \hbox{\cf (1 2 3)} is a list of | |
4975 | @c integers. To be more precise, suppose \var{D} is some data type. (Any | |
4976 | @c predicate defines a data type consisting of those objects of which the | |
4977 | @c predicate is true.) Then | |
4978 | ||
4979 | @c \begin{itemize} | |
4980 | @c \item The empty list is a list of \var{D}. | |
4981 | @c \item If \var{list} is a list of \var{D}, then any pair whose cdr is | |
4982 | @c \var{list} and whose car is an element of the data type \var{D} is also a | |
4983 | @c list of \var{D}. | |
4984 | @c \item There are no other lists of \var{D}. | |
4985 | @c \end{itemize} | |
4986 | ||
4987 | Within literal expressions and representations of objects read by the | |
4988 | @code{read} procedure, the forms @t{'}@r{<datum>}, | |
4989 | @vindex ' | |
4990 | @vindex @w{read} | |
4991 | @t{`}@r{<datum>}, @t{,}@r{<datum>}, and | |
4992 | @vindex , | |
4993 | @t{,@@}@r{<datum>} denote two-ele@-ment lists whose first elements are | |
4994 | the symbols @code{quote}, @code{quasiquote}, @w{@code{unquote}}, and | |
4995 | @vindex @w{unquote} | |
4996 | @vindex @w{quasiquote} | |
4997 | @vindex @w{quote} | |
4998 | @code{unquote-splicing}, respectively. The second element in each case | |
4999 | @vindex @w{unquote-splicing} | |
5000 | is @r{<datum>}. This convention is supported so that arbitrary Scheme | |
5001 | programs may be represented as lists. | |
5002 | @ignore todo | |
5003 | Can or need this be stated | |
5004 | more carefully? | |
5005 | @end ignore | |
5006 | That is, according to Scheme's grammar, every | |
5007 | <expression> is also a <datum> (see section @pxref{External representation}). | |
5008 | Among other things, this permits the use of the @samp{read} procedure to | |
5009 | parse Scheme programs. See section @ref{External representations}. | |
5010 | ||
5011 | ||
5012 | ||
5013 | @deffn {procedure} pair? obj | |
5014 | ||
5015 | @samp{Pair?} returns @t{#t} if @var{obj} is a pair, and otherwise | |
5016 | returns @t{#f}. | |
5017 | ||
5018 | ||
5019 | @format | |
5020 | @t{(pair? '(a . b)) ==> #t | |
5021 | (pair? '(a b c)) ==> #t | |
5022 | (pair? '()) ==> #f | |
5023 | (pair? '#(a b)) ==> #f | |
5024 | } | |
5025 | @end format | |
5026 | ||
5027 | @end deffn | |
5028 | ||
5029 | ||
5030 | ||
5031 | @deffn {procedure} cons obj1 obj2 | |
5032 | ||
5033 | Returns a newly allocated pair whose car is @var{obj1} and whose cdr is | |
5034 | @var{obj2}. The pair is guaranteed to be different (in the sense of | |
5035 | @samp{eqv?}) from every existing object. | |
5036 | ||
5037 | ||
5038 | @format | |
5039 | @t{(cons 'a '()) ==> (a) | |
5040 | (cons '(a) '(b c d)) ==> ((a) b c d) | |
5041 | (cons "a" '(b c)) ==> ("a" b c) | |
5042 | (cons 'a 3) ==> (a . 3) | |
5043 | (cons '(a b) 'c) ==> ((a b) . c) | |
5044 | } | |
5045 | @end format | |
5046 | ||
5047 | @end deffn | |
5048 | ||
5049 | ||
5050 | ||
5051 | @deffn {procedure} car pair | |
5052 | ||
5053 | @ignore nodomain | |
5054 | @var{Pair} must be a pair. | |
5055 | @end ignore | |
5056 | ||
5057 | Returns the contents of the car field of @var{pair}. Note that it is an | |
5058 | error to take the car of the empty list. | |
5059 | @cindex @w{empty list} | |
5060 | ||
5061 | ||
5062 | @format | |
5063 | @t{(car '(a b c)) ==> a | |
5064 | (car '((a) b c d)) ==> (a) | |
5065 | (car '(1 . 2)) ==> 1 | |
5066 | (car '()) ==> @emph{error} | |
5067 | } | |
5068 | @end format | |
5069 | ||
5070 | ||
5071 | @end deffn | |
5072 | ||
5073 | ||
5074 | ||
5075 | @deffn {procedure} cdr pair | |
5076 | ||
5077 | @ignore nodomain | |
5078 | @var{Pair} must be a pair. | |
5079 | @end ignore | |
5080 | ||
5081 | Returns the contents of the cdr field of @var{pair}. | |
5082 | Note that it is an error to take the cdr of the empty list. | |
5083 | ||
5084 | ||
5085 | @format | |
5086 | @t{(cdr '((a) b c d)) ==> (b c d) | |
5087 | (cdr '(1 . 2)) ==> 2 | |
5088 | (cdr '()) ==> @emph{error} | |
5089 | } | |
5090 | @end format | |
5091 | ||
5092 | ||
5093 | @end deffn | |
5094 | ||
5095 | ||
5096 | ||
5097 | @deffn {procedure} set-car! pair obj | |
5098 | ||
5099 | @ignore nodomain | |
5100 | @var{Pair} must be a pair. | |
5101 | @end ignore | |
5102 | ||
5103 | Stores @var{obj} in the car field of @var{pair}. | |
5104 | The value returned by @samp{set-car!} is unspecified. | |
5105 | @c <!> | |
5106 | @c This procedure can be very confusing if used indiscriminately. | |
5107 | ||
5108 | ||
5109 | @format | |
5110 | @t{(define (f) (list 'not-a-constant-list)) | |
5111 | (define (g) '(constant-list)) | |
5112 | (set-car! (f) 3) ==> @emph{unspecified} | |
5113 | (set-car! (g) 3) ==> @emph{error} | |
5114 | } | |
5115 | @end format | |
5116 | ||
5117 | ||
5118 | @end deffn | |
5119 | ||
5120 | ||
5121 | ||
5122 | @deffn {procedure} set-cdr! pair obj | |
5123 | ||
5124 | @ignore nodomain | |
5125 | @var{Pair} must be a pair. | |
5126 | @end ignore | |
5127 | ||
5128 | Stores @var{obj} in the cdr field of @var{pair}. | |
5129 | The value returned by @samp{set-cdr!} is unspecified. | |
5130 | @c <!> | |
5131 | @c This procedure can be very confusing if used indiscriminately. | |
5132 | ||
5133 | @end deffn | |
5134 | ||
5135 | ||
5136 | ||
5137 | ||
5138 | ||
5139 | ||
5140 | @deffn {library procedure} caar pair | |
5141 | @deffnx {library procedure} cadr pair | |
5142 | ||
5143 | @deffnx { @w{ @dots{}}} @w{ @dots{}} | |
5144 | ||
5145 | @deffnx {library procedure} cdddar pair | |
5146 | @deffnx {library procedure} cddddr pair | |
5147 | ||
5148 | These procedures are compositions of @samp{car} and @samp{cdr}, where | |
5149 | for example @samp{caddr} could be defined by | |
5150 | ||
5151 | ||
5152 | @format | |
5153 | @t{(define caddr (lambda (x) (car (cdr (cdr x)))))@r{.} | |
5154 | } | |
5155 | @end format | |
5156 | ||
5157 | ||
5158 | Arbitrary compositions, up to four deep, are provided. There are | |
5159 | twenty-eight of these procedures in all. | |
5160 | ||
5161 | @end deffn | |
5162 | ||
5163 | ||
5164 | ||
5165 | @deffn {library procedure} null? obj | |
5166 | ||
5167 | Returns @t{#t} if @var{obj} is the empty list, | |
5168 | @cindex @w{empty list} | |
5169 | otherwise returns @t{#f}. | |
5170 | ||
5171 | @c \begin{note} | |
5172 | @c In implementations in which the empty | |
5173 | @c list is the same as \schfalse{}, {\cf null?} will return \schtrue{} | |
5174 | @c if \var{obj} is \schfalse{}. | |
5175 | @c \end{note} | |
5176 | ||
5177 | @end deffn | |
5178 | ||
5179 | ||
5180 | @deffn {library procedure} list? obj | |
5181 | ||
5182 | Returns @t{#t} if @var{obj} is a list, otherwise returns @t{#f}. | |
5183 | By definition, all lists have finite length and are terminated by | |
5184 | the empty list. | |
5185 | ||
5186 | ||
5187 | @format | |
5188 | @t{ (list? '(a b c)) ==> #t | |
5189 | (list? '()) ==> #t | |
5190 | (list? '(a . b)) ==> #f | |
5191 | (let ((x (list 'a))) | |
5192 | (set-cdr! x x) | |
5193 | (list? x)) ==> #f | |
5194 | } | |
5195 | @end format | |
5196 | ||
5197 | @end deffn | |
5198 | ||
5199 | ||
5200 | ||
5201 | @deffn {library procedure} list @var{obj} @dots{}, | |
5202 | ||
5203 | Returns a newly allocated list of its arguments. | |
5204 | ||
5205 | ||
5206 | @format | |
5207 | @t{(list 'a (+ 3 4) 'c) ==> (a 7 c) | |
5208 | (list) ==> () | |
5209 | } | |
5210 | @end format | |
5211 | ||
5212 | @end deffn | |
5213 | ||
5214 | ||
5215 | ||
5216 | @deffn {library procedure} length list | |
5217 | ||
5218 | @ignore nodomain | |
5219 | @var{List} must be a list. | |
5220 | @end ignore | |
5221 | ||
5222 | Returns the length of @var{list}. | |
5223 | ||
5224 | ||
5225 | @format | |
5226 | @t{(length '(a b c)) ==> 3 | |
5227 | (length '(a (b) (c d e))) ==> 3 | |
5228 | (length '()) ==> 0 | |
5229 | } | |
5230 | @end format | |
5231 | ||
5232 | @end deffn | |
5233 | ||
5234 | ||
5235 | ||
5236 | @deffn {library procedure} append list @dots{}, | |
5237 | ||
5238 | @ignore nodomain | |
5239 | All @var{list}s should be lists. | |
5240 | @end ignore | |
5241 | ||
5242 | Returns a list consisting of the elements of the first @var{list} | |
5243 | followed by the elements of the other @var{list}s. | |
5244 | ||
5245 | ||
5246 | @format | |
5247 | @t{(append '(x) '(y)) ==> (x y) | |
5248 | (append '(a) '(b c d)) ==> (a b c d) | |
5249 | (append '(a (b)) '((c))) ==> (a (b) (c)) | |
5250 | } | |
5251 | @end format | |
5252 | ||
5253 | ||
5254 | The resulting list is always newly allocated, except that it shares | |
5255 | structure with the last @var{list} argument. The last argument may | |
5256 | actually be any object; an improper list results if the last argument is not a | |
5257 | proper list. | |
5258 | @ignore todo | |
5259 | This is pretty awkward. I should get Bartley to fix this. | |
5260 | @end ignore | |
5261 | ||
5262 | ||
5263 | ||
5264 | @format | |
5265 | @t{(append '(a b) '(c . d)) ==> (a b c . d) | |
5266 | (append '() 'a) ==> a | |
5267 | } | |
5268 | @end format | |
5269 | ||
5270 | @end deffn | |
5271 | ||
5272 | ||
5273 | ||
5274 | @deffn {library procedure} reverse list | |
5275 | ||
5276 | @ignore nodomain | |
5277 | @var{List} must be a list. | |
5278 | @end ignore | |
5279 | ||
5280 | Returns a newly allocated list consisting of the elements of @var{list} | |
5281 | in reverse order. | |
5282 | ||
5283 | ||
5284 | @format | |
5285 | @t{(reverse '(a b c)) ==> (c b a) | |
5286 | (reverse '(a (b c) d (e (f)))) | |
5287 | ==> ((e (f)) d (b c) a) | |
5288 | } | |
5289 | @end format | |
5290 | ||
5291 | @end deffn | |
5292 | ||
5293 | ||
5294 | ||
5295 | @deffn {library procedure} list-tail list @var{k} | |
5296 | ||
5297 | Returns the sublist of @var{list} obtained by omitting the first @var{k} | |
5298 | elements. It is an error if @var{list} has fewer than @var{k} elements. | |
5299 | @samp{List-tail} could be defined by | |
5300 | ||
5301 | ||
5302 | @format | |
5303 | @t{(define list-tail | |
5304 | (lambda (x k) | |
5305 | (if (zero? k) | |
5306 | x | |
5307 | (list-tail (cdr x) (- k 1))))) | |
5308 | } | |
5309 | @end format | |
5310 | ||
5311 | @end deffn | |
5312 | ||
5313 | ||
5314 | ||
5315 | @deffn {library procedure} list-ref list @var{k} | |
5316 | ||
5317 | Returns the @var{k}th element of @var{list}. (This is the same | |
5318 | as the car of @t{(list-tail @var{list} @var{k})}.) | |
5319 | It is an error if @var{list} has fewer than @var{k} elements. | |
5320 | ||
5321 | ||
5322 | @format | |
5323 | @t{(list-ref '(a b c d) 2) ==> c | |
5324 | (list-ref '(a b c d) | |
5325 | (inexact->exact (round 1.8))) | |
5326 | ==> c | |
5327 | } | |
5328 | @end format | |
5329 | ||
5330 | @end deffn | |
5331 | ||
5332 | ||
5333 | @c \begin{entry}{% | |
5334 | @c \proto{last-pair}{ list}{library procedure}} | |
5335 | ||
5336 | @c Returns the last pair in the nonempty, possibly improper, list \var{list}. | |
5337 | @c {\cf Last-pair} could be defined by | |
5338 | ||
5339 | @c \begin{scheme} | |
5340 | @c (define last-pair | |
5341 | @c (lambda (x) | |
5342 | @c (if (pair? (cdr x)) | |
5343 | @c (last-pair (cdr x)) | |
5344 | @c x)))% | |
5345 | @c \end{scheme} | |
5346 | ||
5347 | @c \end{entry} | |
5348 | ||
5349 | ||
5350 | ||
5351 | @deffn {library procedure} memq obj list | |
5352 | @deffnx {library procedure} memv obj list | |
5353 | @deffnx {library procedure} member obj list | |
5354 | ||
5355 | These procedures return the first sublist of @var{list} whose car is | |
5356 | @var{obj}, where the sublists of @var{list} are the non-empty lists | |
5357 | returned by @t{(list-tail @var{list} @var{k})} for @var{k} less | |
5358 | than the length of @var{list}. If | |
5359 | @var{obj} does not occur in @var{list}, then @t{#f} (not the empty list) is | |
5360 | returned. @samp{Memq} uses @samp{eq?} to compare @var{obj} with the elements of | |
5361 | @var{list}, while @samp{memv} uses @samp{eqv?} and @samp{member} uses @samp{equal?}. | |
5362 | ||
5363 | ||
5364 | @format | |
5365 | @t{(memq 'a '(a b c)) ==> (a b c) | |
5366 | (memq 'b '(a b c)) ==> (b c) | |
5367 | (memq 'a '(b c d)) ==> #f | |
5368 | (memq (list 'a) '(b (a) c)) ==> #f | |
5369 | (member (list 'a) | |
5370 | '(b (a) c)) ==> ((a) c) | |
5371 | (memq 101 '(100 101 102)) ==> @emph{unspecified} | |
5372 | (memv 101 '(100 101 102)) ==> (101 102) | |
5373 | } | |
5374 | @end format | |
5375 | ||
5376 | ||
5377 | @end deffn | |
5378 | ||
5379 | ||
5380 | ||
5381 | @deffn {library procedure} assq obj alist | |
5382 | @deffnx {library procedure} assv obj alist | |
5383 | @deffnx {library procedure} assoc obj alist | |
5384 | ||
5385 | @var{Alist} (for ``association list'') must be a list of | |
5386 | pairs. These procedures find the first pair in @var{alist} whose car field is @var{obj}, | |
5387 | and returns that pair. If no pair in @var{alist} has @var{obj} as its | |
5388 | car, then @t{#f} (not the empty list) is returned. @samp{Assq} uses | |
5389 | @samp{eq?} to compare @var{obj} with the car fields of the pairs in @var{alist}, | |
5390 | while @samp{assv} uses @samp{eqv?} and @samp{assoc} uses @samp{equal?}. | |
5391 | ||
5392 | ||
5393 | @format | |
5394 | @t{(define e '((a 1) (b 2) (c 3))) | |
5395 | (assq 'a e) ==> (a 1) | |
5396 | (assq 'b e) ==> (b 2) | |
5397 | (assq 'd e) ==> #f | |
5398 | (assq (list 'a) '(((a)) ((b)) ((c)))) | |
5399 | ==> #f | |
5400 | (assoc (list 'a) '(((a)) ((b)) ((c)))) | |
5401 | ==> ((a)) | |
5402 | (assq 5 '((2 3) (5 7) (11 13))) | |
5403 | ==> @emph{unspecified} | |
5404 | (assv 5 '((2 3) (5 7) (11 13))) | |
5405 | ==> (5 7) | |
5406 | } | |
5407 | @end format | |
5408 | ||
5409 | ||
5410 | ||
5411 | ||
5412 | @quotation | |
5413 | @emph{Rationale:} | |
5414 | Although they are ordinarily used as predicates, | |
5415 | @samp{memq}, @samp{memv}, @samp{member}, @samp{assq}, @samp{assv}, and @samp{assoc} do not | |
5416 | have question marks in their names because they return useful values rather | |
5417 | than just @t{#t} or @t{#f}. | |
5418 | @end quotation | |
5419 | ||
5420 | @end deffn | |
5421 | ||
5422 | ||
5423 | @node Symbols, Characters, Pairs and lists, Other data types | |
5424 | @subsection Symbols | |
5425 | ||
5426 | ||
5427 | ||
5428 | Symbols are objects whose usefulness rests on the fact that two | |
5429 | symbols are identical (in the sense of @samp{eqv?}) if and only if their | |
5430 | names are spelled the same way. This is exactly the property needed to | |
5431 | represent identifiers in programs, and so most | |
5432 | @cindex @w{identifier} | |
5433 | implementations of Scheme use them internally for that purpose. Symbols | |
5434 | are useful for many other applications; for instance, they may be used | |
5435 | the way enumerated values are used in Pascal. | |
5436 | ||
5437 | The rules for writing a symbol are exactly the same as the rules for | |
5438 | writing an identifier; see sections @ref{Identifiers} | |
5439 | and @ref{Lexical structure}. | |
5440 | ||
5441 | It is guaranteed that any symbol that has been returned as part of | |
5442 | a literal expression, or read using the @samp{read} procedure, and | |
5443 | subsequently written out using the @samp{write} procedure, will read back | |
5444 | in as the identical symbol (in the sense of @samp{eqv?}). The | |
5445 | @samp{string->symbol} procedure, however, can create symbols for | |
5446 | which this write/read invariance may not hold because their names | |
5447 | contain special characters or letters in the non-standard case. | |
5448 | ||
5449 | ||
5450 | @quotation | |
5451 | @emph{Note:} | |
5452 | Some implementations of Scheme have a feature known as ``slashification'' | |
5453 | in order to guarantee write/read invariance for all symbols, but | |
5454 | historically the most important use of this feature has been to | |
5455 | compensate for the lack of a string data type. | |
5456 | ||
5457 | Some implementations also have ``uninterned symbols'', which | |
5458 | defeat write/read invariance even in implementations with slashification, | |
5459 | and also generate exceptions to the rule that two symbols are the same | |
5460 | if and only if their names are spelled the same. | |
5461 | @end quotation | |
5462 | ||
5463 | ||
5464 | ||
5465 | ||
5466 | @deffn {procedure} symbol? obj | |
5467 | ||
5468 | Returns @t{#t} if @var{obj} is a symbol, otherwise returns @t{#f}. | |
5469 | ||
5470 | ||
5471 | @format | |
5472 | @t{(symbol? 'foo) ==> #t | |
5473 | (symbol? (car '(a b))) ==> #t | |
5474 | (symbol? "bar") ==> #f | |
5475 | (symbol? 'nil) ==> #t | |
5476 | (symbol? '()) ==> #f | |
5477 | (symbol? #f) ==> #f | |
5478 | } | |
5479 | @end format | |
5480 | ||
5481 | @end deffn | |
5482 | ||
5483 | ||
5484 | ||
5485 | @deffn {procedure} symbol->string symbol | |
5486 | ||
5487 | Returns the name of @var{symbol} as a string. If the symbol was part of | |
5488 | an object returned as the value of a literal expression | |
5489 | (section @pxref{Literal expressions}) or by a call to the @samp{read} procedure, | |
5490 | and its name contains alphabetic characters, then the string returned | |
5491 | will contain characters in the implementation's preferred standard | |
5492 | case---some implementations will prefer upper case, others lower case. | |
5493 | If the symbol was returned by @samp{string->symbol}, the case of | |
5494 | characters in the string returned will be the same as the case in the | |
5495 | string that was passed to @samp{string->symbol}. It is an error | |
5496 | to apply mutation procedures like @code{string-set!} to strings returned | |
5497 | @vindex @w{string-set!} | |
5498 | by this procedure. | |
5499 | ||
5500 | The following examples assume that the implementation's standard case is | |
5501 | lower case: | |
5502 | ||
5503 | ||
5504 | @format | |
5505 | @t{(symbol->string 'flying-fish) | |
5506 | ==> "flying-fish" | |
5507 | (symbol->string 'Martin) ==> "martin" | |
5508 | (symbol->string | |
5509 | (string->symbol "Malvina")) | |
5510 | ==> "Malvina" | |
5511 | } | |
5512 | @end format | |
5513 | ||
5514 | @end deffn | |
5515 | ||
5516 | ||
5517 | ||
5518 | @deffn {procedure} string->symbol string | |
5519 | ||
5520 | Returns the symbol whose name is @var{string}. This procedure can | |
5521 | create symbols with names containing special characters or letters in | |
5522 | the non-standard case, but it is usually a bad idea to create such | |
5523 | symbols because in some implementations of Scheme they cannot be read as | |
5524 | themselves. See @samp{symbol->string}. | |
5525 | ||
5526 | The following examples assume that the implementation's standard case is | |
5527 | lower case: | |
5528 | ||
5529 | ||
5530 | @format | |
5531 | @t{(eq? 'mISSISSIppi 'mississippi) | |
5532 | ==> #t | |
5533 | (string->symbol "mISSISSIppi") | |
5534 | ==> | |
5535 | @r{}the symbol with name "mISSISSIppi" | |
5536 | (eq? 'bitBlt (string->symbol "bitBlt")) | |
5537 | ==> #f | |
5538 | (eq? 'JollyWog | |
5539 | (string->symbol | |
5540 | (symbol->string 'JollyWog))) | |
5541 | ==> #t | |
5542 | (string=? "K. Harper, M.D." | |
5543 | (symbol->string | |
5544 | (string->symbol "K. Harper, M.D."))) | |
5545 | ==> #t | |
5546 | } | |
5547 | @end format | |
5548 | ||
5549 | ||
5550 | @end deffn | |
5551 | ||
5552 | ||
5553 | @node Characters, Strings, Symbols, Other data types | |
5554 | @subsection Characters | |
5555 | ||
5556 | ||
5557 | ||
5558 | Characters are objects that represent printed characters such as | |
5559 | letters and digits. | |
5560 | @c There is no requirement that the data type of | |
5561 | @c characters be disjoint from other data types; implementations are | |
5562 | @c encouraged to have a separate character data type, but may choose to | |
5563 | @c represent characters as integers, strings, or some other type. | |
5564 | Characters are written using the notation #\@r{<character>} | |
5565 | or #\@r{<character name>}. | |
5566 | For example: | |
5567 | ||
5568 | ||
5569 | ||
5570 | @center @c begin-tabular | |
5571 | @quotation | |
5572 | @table @asis | |
5573 | @item @t{#\a} | |
5574 | ; lower case letter | |
5575 | @item @t{#\A} | |
5576 | ; upper case letter | |
5577 | @item @t{#\(} | |
5578 | ; left parenthesis | |
5579 | @item @t{#\ } | |
5580 | ; the space character | |
5581 | @item @t{#\space} | |
5582 | ; the preferred way to write a space | |
5583 | @item @t{#\newline} | |
5584 | ; the newline character | |
5585 | @item | |
5586 | @end table | |
5587 | @end quotation | |
5588 | ||
5589 | ||
5590 | ||
5591 | ||
5592 | Case is significant in #\@r{<character>}, but not in | |
5593 | #\@r{<character name>}. | |
5594 | @c \hyper doesn't | |
5595 | ||
5596 | @c allow a linebreak | |
5597 | If @r{<character>} in | |
5598 | #\@r{<character>} is alphabetic, then the character | |
5599 | following @r{<character>} must be a delimiter character such as a | |
5600 | space or parenthesis. This rule resolves the ambiguous case where, for | |
5601 | example, the sequence of characters ``@t{#\ space}'' | |
5602 | could be taken to be either a representation of the space character or a | |
5603 | representation of the character ``@t{#\ s}'' followed | |
5604 | by a representation of the symbol ``@t{pace}.'' | |
5605 | ||
5606 | @ignore todo | |
5607 | Fix | |
5608 | @end ignore | |
5609 | ||
5610 | Characters written in the #\ notation are self-evaluating. | |
5611 | That is, they do not have to be quoted in programs. | |
5612 | @c The \sharpsign\backwhack{} | |
5613 | @c notation is not an essential part of Scheme, however. Even implementations | |
5614 | @c that support the \sharpsign\backwhack{} notation for input do not have to | |
5615 | @c support it for output. | |
5616 | ||
5617 | Some of the procedures that operate on characters ignore the | |
5618 | difference between upper case and lower case. The procedures that | |
5619 | ignore case have @w{``@t{-ci}''} (for ``case | |
5620 | insensitive'') embedded in their names. | |
5621 | ||
5622 | ||
5623 | ||
5624 | @deffn {procedure} char? obj | |
5625 | ||
5626 | Returns @t{#t} if @var{obj} is a character, otherwise returns @t{#f}. | |
5627 | ||
5628 | @end deffn | |
5629 | ||
5630 | ||
5631 | ||
5632 | @deffn {procedure} char=? char1 char2 | |
5633 | @deffnx {procedure} char<? char1 char2 | |
5634 | @deffnx {procedure} char>? char1 char2 | |
5635 | @deffnx {procedure} char<=? char1 char2 | |
5636 | @deffnx {procedure} char>=? char1 char2 | |
5637 | ||
5638 | ||
5639 | @ignore nodomain | |
5640 | Both @var{char1} and @var{char2} must be characters. | |
5641 | @end ignore | |
5642 | ||
5643 | These procedures impose a total ordering on the set of characters. It | |
5644 | is guaranteed that under this ordering: | |
5645 | ||
5646 | ||
5647 | ||
5648 | @itemize @bullet | |
5649 | ||
5650 | @item | |
5651 | The upper case characters are in order. For example, @samp{(char<? #\A #\B)} returns @t{#t}. | |
5652 | @item | |
5653 | The lower case characters are in order. For example, @samp{(char<? #\a #\b)} returns @t{#t}. | |
5654 | @item | |
5655 | The digits are in order. For example, @samp{(char<? #\0 #\9)} returns @t{#t}. | |
5656 | @item | |
5657 | Either all the digits precede all the upper case letters, or vice versa. | |
5658 | @item | |
5659 | Either all the digits precede all the lower case letters, or vice versa. | |
5660 | ||
5661 | @end itemize | |
5662 | ||
5663 | ||
5664 | Some implementations may generalize these procedures to take more than | |
5665 | two arguments, as with the corresponding numerical predicates. | |
5666 | ||
5667 | @end deffn | |
5668 | ||
5669 | ||
5670 | ||
5671 | @deffn {library procedure} char-ci=? char1 char2 | |
5672 | @deffnx {library procedure} char-ci<? char1 char2 | |
5673 | @deffnx {library procedure} char-ci>? char1 char2 | |
5674 | @deffnx {library procedure} char-ci<=? char1 char2 | |
5675 | @deffnx {library procedure} char-ci>=? char1 char2 | |
5676 | ||
5677 | @ignore nodomain | |
5678 | Both @var{char1} and @var{char2} must be characters. | |
5679 | @end ignore | |
5680 | ||
5681 | These procedures are similar to @samp{char=?} et cetera, but they treat | |
5682 | upper case and lower case letters as the same. For example, @samp{(char-ci=? #\A #\a)} returns @t{#t}. Some | |
5683 | implementations may generalize these procedures to take more than two | |
5684 | arguments, as with the corresponding numerical predicates. | |
5685 | ||
5686 | @end deffn | |
5687 | ||
5688 | ||
5689 | ||
5690 | @deffn {library procedure} char-alphabetic? char | |
5691 | @deffnx {library procedure} char-numeric? char | |
5692 | @deffnx {library procedure} char-whitespace? char | |
5693 | @deffnx {library procedure} char-upper-case? letter | |
5694 | @deffnx {library procedure} char-lower-case? letter | |
5695 | ||
5696 | These procedures return @t{#t} if their arguments are alphabetic, | |
5697 | numeric, whitespace, upper case, or lower case characters, respectively, | |
5698 | otherwise they return @t{#f}. The following remarks, which are specific to | |
5699 | the ASCII character set, are intended only as a guide: The alphabetic characters | |
5700 | are the 52 upper and lower case letters. The numeric characters are the | |
5701 | ten decimal digits. The whitespace characters are space, tab, line | |
5702 | feed, form feed, and carriage return. | |
5703 | @end deffn | |
5704 | ||
5705 | ||
5706 | @c %R4%%\begin{entry}{% | |
5707 | @c \proto{char-upper-case?}{ letter}{procedure} | |
5708 | @c \proto{char-lower-case?}{ letter}{procedure}} | |
5709 | ||
5710 | @c \domain{\var{Letter} must be an alphabetic character.} | |
5711 | @c These procedures return \schtrue{} if their arguments are upper case or | |
5712 | @c lower case characters, respectively, otherwise they return \schfalse. | |
5713 | @c \end{entry} | |
5714 | ||
5715 | ||
5716 | ||
5717 | @deffn {procedure} char->integer char | |
5718 | @deffnx {procedure} integer->char @var{n} | |
5719 | ||
5720 | Given a character, @samp{char->integer} returns an exact integer | |
5721 | representation of the character. Given an exact integer that is the image of | |
5722 | a character under @samp{char->integer}, @samp{integer->char} | |
5723 | returns that character. These procedures implement order-preserving isomorphisms | |
5724 | between the set of characters under the @code{char<=?} ordering and some | |
5725 | @vindex @w{char<=?} | |
5726 | subset of the integers under the @samp{<=} ordering. That is, if | |
5727 | ||
5728 | ||
5729 | @format | |
5730 | @t{(char<=? @var{a} @var{b}) @result{} #t @r{}and (<= @var{x} @var{y}) @result{} #t | |
5731 | } | |
5732 | @end format | |
5733 | ||
5734 | ||
5735 | ||
5736 | @noindent | |
5737 | and @var{x} and @var{y} are in the domain of | |
5738 | @samp{integer->char}, then | |
5739 | ||
5740 | ||
5741 | @format | |
5742 | @t{(<= (char->integer @var{a}) | |
5743 | (char->integer @var{b})) ==> #t | |
5744 | ||
5745 | (char<=? (integer->char @var{x}) | |
5746 | (integer->char @var{y})) ==> #t | |
5747 | } | |
5748 | @end format | |
5749 | ||
5750 | ||
5751 | @end deffn | |
5752 | ||
5753 | ||
5754 | ||
5755 | @deffn {library procedure} char-upcase char | |
5756 | @deffnx {library procedure} char-downcase char | |
5757 | ||
5758 | @ignore nodomain | |
5759 | @var{Char} must be a character. | |
5760 | @end ignore | |
5761 | ||
5762 | These procedures return a character @var{char2} such that @samp{(char-ci=? @var{char} @var{char2})}. In addition, if @var{char} is | |
5763 | alphabetic, then the result of @samp{char-upcase} is upper case and the | |
5764 | result of @samp{char-downcase} is lower case. | |
5765 | ||
5766 | @end deffn | |
5767 | ||
5768 | ||
5769 | @node Strings, Vectors, Characters, Other data types | |
5770 | @subsection Strings | |
5771 | ||
5772 | ||
5773 | ||
5774 | Strings are sequences of characters. | |
5775 | @c In some implementations of Scheme | |
5776 | @c they are immutable; other implementations provide destructive procedures | |
5777 | @c such as {\cf string-set!}\ that alter string objects. | |
5778 | Strings are written as sequences of characters enclosed within doublequotes | |
5779 | (@samp{"}). A doublequote can be written inside a string only by escaping | |
5780 | it with a backslash (\), as in | |
5781 | ||
5782 | ||
5783 | @example | |
5784 | ||
5785 | "The word \"recursion\" has many meanings." | |
5786 | ||
5787 | @end example | |
5788 | ||
5789 | ||
5790 | A backslash can be written inside a string only by escaping it with another | |
5791 | backslash. Scheme does not specify the effect of a backslash within a | |
5792 | string that is not followed by a doublequote or backslash. | |
5793 | ||
5794 | A string constant may continue from one line to the next, but | |
5795 | the exact contents of such a string are unspecified. | |
5796 | @c this is | |
5797 | @c usually a bad idea because | |
5798 | @c the exact effect may vary from one computer | |
5799 | @c system to another. | |
5800 | ||
5801 | The @emph{length} of a string is the number of characters that it | |
5802 | contains. This number is an exact, non-negative integer that is fixed when the | |
5803 | string is created. The @dfn{valid indexes} of a string are the | |
5804 | @cindex @w{valid indexes} | |
5805 | exact non-negative integers less than the length of the string. The first | |
5806 | character of a string has index 0, the second has index 1, and so on. | |
5807 | ||
5808 | In phrases such as ``the characters of @var{string} beginning with | |
5809 | index @var{start} and ending with index @var{end},'' it is understood | |
5810 | that the index @var{start} is inclusive and the index @var{end} is | |
5811 | exclusive. Thus if @var{start} and @var{end} are the same index, a null | |
5812 | substring is referred to, and if @var{start} is zero and @var{end} is | |
5813 | the length of @var{string}, then the entire string is referred to. | |
5814 | ||
5815 | Some of the procedures that operate on strings ignore the | |
5816 | difference between upper and lower case. The versions that ignore case | |
5817 | have @w{``@samp{-ci}''} (for ``case insensitive'') embedded in their | |
5818 | names. | |
5819 | ||
5820 | ||
5821 | ||
5822 | @deffn {procedure} string? obj | |
5823 | ||
5824 | Returns @t{#t} if @var{obj} is a string, otherwise returns @t{#f}. | |
5825 | @end deffn | |
5826 | ||
5827 | ||
5828 | ||
5829 | @deffn {procedure} make-string @var{k} | |
5830 | @deffnx {procedure} make-string @var{k} char | |
5831 | ||
5832 | @c \domain{\vr{k} must be a non-negative integer, and \var{char} must be | |
5833 | @c a character.} | |
5834 | @samp{Make-string} returns a newly allocated string of | |
5835 | length @var{k}. If @var{char} is given, then all elements of the string | |
5836 | are initialized to @var{char}, otherwise the contents of the | |
5837 | @var{string} are unspecified. | |
5838 | ||
5839 | @end deffn | |
5840 | ||
5841 | ||
5842 | @deffn {library procedure} string char @dots{}, | |
5843 | ||
5844 | Returns a newly allocated string composed of the arguments. | |
5845 | ||
5846 | @end deffn | |
5847 | ||
5848 | ||
5849 | @deffn {procedure} string-length string | |
5850 | ||
5851 | Returns the number of characters in the given @var{string}. | |
5852 | @end deffn | |
5853 | ||
5854 | ||
5855 | ||
5856 | @deffn {procedure} string-ref string @var{k} | |
5857 | ||
5858 | @var{k} must be a valid index of @var{string}. | |
5859 | @samp{String-ref} returns character @var{k} of @var{string} using zero-origin indexing. | |
5860 | @end deffn | |
5861 | ||
5862 | ||
5863 | ||
5864 | @deffn {procedure} string-set! string k char | |
5865 | ||
5866 | ||
5867 | @c \var{String} must be a string, | |
5868 | @var{k} must be a valid index of @var{string} | |
5869 | @c , and \var{char} must be a character | |
5870 | . | |
5871 | @samp{String-set!} stores @var{char} in element @var{k} of @var{string} | |
5872 | and returns an unspecified value. | |
5873 | @c <!> | |
5874 | ||
5875 | ||
5876 | @format | |
5877 | @t{(define (f) (make-string 3 #\*)) | |
5878 | (define (g) "***") | |
5879 | (string-set! (f) 0 #\?) ==> @emph{unspecified} | |
5880 | (string-set! (g) 0 #\?) ==> @emph{error} | |
5881 | (string-set! (symbol->string 'immutable) | |
5882 | 0 | |
5883 | #\?) ==> @emph{error} | |
5884 | } | |
5885 | @end format | |
5886 | ||
5887 | ||
5888 | @end deffn | |
5889 | ||
5890 | ||
5891 | ||
5892 | @deffn {library procedure} string=? string1 string2 | |
5893 | @deffnx {library procedure} string-ci=? string1 string2 | |
5894 | ||
5895 | Returns @t{#t} if the two strings are the same length and contain the same | |
5896 | characters in the same positions, otherwise returns @t{#f}. | |
5897 | @samp{String-ci=?} treats | |
5898 | upper and lower case letters as though they were the same character, but | |
5899 | @samp{string=?} treats upper and lower case as distinct characters. | |
5900 | ||
5901 | @end deffn | |
5902 | ||
5903 | ||
5904 | ||
5905 | @deffn {library procedure} string<? string1 string2 | |
5906 | @deffnx {library procedure} string>? string1 string2 | |
5907 | @deffnx {library procedure} string<=? string1 string2 | |
5908 | @deffnx {library procedure} string>=? string1 string2 | |
5909 | @deffnx {library procedure} string-ci<? string1 string2 | |
5910 | @deffnx {library procedure} string-ci>? string1 string2 | |
5911 | @deffnx {library procedure} string-ci<=? string1 string2 | |
5912 | @deffnx {library procedure} string-ci>=? string1 string2 | |
5913 | ||
5914 | These procedures are the lexicographic extensions to strings of the | |
5915 | corresponding orderings on characters. For example, @samp{string<?} is | |
5916 | the lexicographic ordering on strings induced by the ordering | |
5917 | @samp{char<?} on characters. If two strings differ in length but | |
5918 | are the same up to the length of the shorter string, the shorter string | |
5919 | is considered to be lexicographically less than the longer string. | |
5920 | ||
5921 | Implementations may generalize these and the @samp{string=?} and | |
5922 | @samp{string-ci=?} procedures to take more than two arguments, as with | |
5923 | the corresponding numerical predicates. | |
5924 | ||
5925 | @end deffn | |
5926 | ||
5927 | ||
5928 | ||
5929 | @deffn {library procedure} substring string start end | |
5930 | ||
5931 | @var{String} must be a string, and @var{start} and @var{end} | |
5932 | must be exact integers satisfying | |
5933 | ||
5934 | ||
5935 | @center 0 <= @var{start} <= @var{end} <= @w{@t{(string-length @var{string})@r{.}}} | |
5936 | ||
5937 | @samp{Substring} returns a newly allocated string formed from the characters of | |
5938 | @var{string} beginning with index @var{start} (inclusive) and ending with index | |
5939 | @var{end} (exclusive). | |
5940 | @end deffn | |
5941 | ||
5942 | ||
5943 | ||
5944 | @deffn {library procedure} string-append @var{string} @dots{}, | |
5945 | ||
5946 | Returns a newly allocated string whose characters form the concatenation of the | |
5947 | given strings. | |
5948 | ||
5949 | @end deffn | |
5950 | ||
5951 | ||
5952 | ||
5953 | @deffn {library procedure} string->list string | |
5954 | @deffnx {library procedure} list->string list | |
5955 | ||
5956 | @samp{String->list} returns a newly allocated list of the | |
5957 | characters that make up the given string. @samp{List->string} | |
5958 | returns a newly allocated string formed from the characters in the list | |
5959 | @var{list}, which must be a list of characters. @samp{String->list} | |
5960 | and @samp{list->string} are | |
5961 | inverses so far as @samp{equal?} is concerned. | |
5962 | @c Implementations that provide | |
5963 | @c destructive operations on strings should ensure that the result of | |
5964 | @c {\cf list\coerce{}string} is newly allocated. | |
5965 | ||
5966 | @end deffn | |
5967 | ||
5968 | ||
5969 | ||
5970 | @deffn {library procedure} string-copy string | |
5971 | ||
5972 | Returns a newly allocated copy of the given @var{string}. | |
5973 | ||
5974 | @end deffn | |
5975 | ||
5976 | ||
5977 | ||
5978 | @deffn {library procedure} string-fill! string char | |
5979 | ||
5980 | Stores @var{char} in every element of the given @var{string} and returns an | |
5981 | unspecified value. | |
5982 | @c <!> | |
5983 | ||
5984 | @end deffn | |
5985 | ||
5986 | ||
5987 | @node Vectors, , Strings, Other data types | |
5988 | @subsection Vectors | |
5989 | ||
5990 | ||
5991 | ||
5992 | Vectors are heterogenous structures whose elements are indexed | |
5993 | by integers. A vector typically occupies less space than a list | |
5994 | of the same length, and the average time required to access a randomly | |
5995 | chosen element is typically less for the vector than for the list. | |
5996 | ||
5997 | The @emph{length} of a vector is the number of elements that it | |
5998 | contains. This number is a non-negative integer that is fixed when the | |
5999 | vector is created. The @emph{valid indexes} of a | |
6000 | @cindex @w{valid indexes} | |
6001 | vector are the exact non-negative integers less than the length of the | |
6002 | vector. The first element in a vector is indexed by zero, and the last | |
6003 | element is indexed by one less than the length of the vector. | |
6004 | ||
6005 | Vectors are written using the notation @t{#(@var{obj} @dots{},)}. | |
6006 | For example, a vector of length 3 containing the number zero in element | |
6007 | 0, the list @samp{(2 2 2 2)} in element 1, and the string @samp{"Anna"} in | |
6008 | element 2 can be written as following: | |
6009 | ||
6010 | ||
6011 | @example | |
6012 | ||
6013 | #(0 (2 2 2 2) "Anna") | |
6014 | ||
6015 | @end example | |
6016 | ||
6017 | ||
6018 | Note that this is the external representation of a vector, not an | |
6019 | expression evaluating to a vector. Like list constants, vector | |
6020 | constants must be quoted: | |
6021 | ||
6022 | ||
6023 | @example | |
6024 | ||
6025 | '#(0 (2 2 2 2) "Anna") | |
6026 | ==> #(0 (2 2 2 2) "Anna") | |
6027 | ||
6028 | @end example | |
6029 | ||
6030 | ||
6031 | @ignore todo | |
6032 | Pitman sez: The visual similarity to lists is bound to be confusing | |
6033 | to some. Elaborate on the distinction. | |
6034 | @end ignore | |
6035 | ||
6036 | ||
6037 | ||
6038 | ||
6039 | @deffn {procedure} vector? obj | |
6040 | ||
6041 | Returns @t{#t} if @var{obj} is a vector, otherwise returns @t{#f}. | |
6042 | @end deffn | |
6043 | ||
6044 | ||
6045 | ||
6046 | @deffn {procedure} make-vector k | |
6047 | @deffnx {procedure} make-vector k fill | |
6048 | ||
6049 | Returns a newly allocated vector of @var{k} elements. If a second | |
6050 | argument is given, then each element is initialized to @var{fill}. | |
6051 | Otherwise the initial contents of each element is unspecified. | |
6052 | ||
6053 | @end deffn | |
6054 | ||
6055 | ||
6056 | ||
6057 | @deffn {library procedure} vector obj @dots{}, | |
6058 | ||
6059 | Returns a newly allocated vector whose elements contain the given | |
6060 | arguments. Analogous to @samp{list}. | |
6061 | ||
6062 | ||
6063 | @format | |
6064 | @t{(vector 'a 'b 'c) ==> #(a b c) | |
6065 | } | |
6066 | @end format | |
6067 | ||
6068 | @end deffn | |
6069 | ||
6070 | ||
6071 | ||
6072 | @deffn {procedure} vector-length vector | |
6073 | ||
6074 | Returns the number of elements in @var{vector} as an exact integer. | |
6075 | @end deffn | |
6076 | ||
6077 | ||
6078 | ||
6079 | @deffn {procedure} vector-ref vector k | |
6080 | ||
6081 | @var{k} must be a valid index of @var{vector}. | |
6082 | @samp{Vector-ref} returns the contents of element @var{k} of | |
6083 | @var{vector}. | |
6084 | ||
6085 | ||
6086 | @format | |
6087 | @t{(vector-ref '#(1 1 2 3 5 8 13 21) | |
6088 | 5) | |
6089 | ==> 8 | |
6090 | (vector-ref '#(1 1 2 3 5 8 13 21) | |
6091 | (let ((i (round (* 2 (acos -1))))) | |
6092 | (if (inexact? i) | |
6093 | (inexact->exact i) | |
6094 | i))) | |
6095 | ==> 13 | |
6096 | } | |
6097 | @end format | |
6098 | ||
6099 | @end deffn | |
6100 | ||
6101 | ||
6102 | ||
6103 | @deffn {procedure} vector-set! vector k obj | |
6104 | ||
6105 | @var{k} must be a valid index of @var{vector}. | |
6106 | @samp{Vector-set!} stores @var{obj} in element @var{k} of @var{vector}. | |
6107 | The value returned by @samp{vector-set!} is unspecified. | |
6108 | @c <!> | |
6109 | ||
6110 | ||
6111 | @format | |
6112 | @t{(let ((vec (vector 0 '(2 2 2 2) "Anna"))) | |
6113 | (vector-set! vec 1 '("Sue" "Sue")) | |
6114 | vec) | |
6115 | ==> #(0 ("Sue" "Sue") "Anna") | |
6116 | ||
6117 | (vector-set! '#(0 1 2) 1 "doe") | |
6118 | ==> @emph{error} ; constant vector | |
6119 | } | |
6120 | @end format | |
6121 | ||
6122 | @end deffn | |
6123 | ||
6124 | ||
6125 | ||
6126 | @deffn {library procedure} vector->list vector | |
6127 | @deffnx {library procedure} list->vector list | |
6128 | ||
6129 | @samp{Vector->list} returns a newly allocated list of the objects contained | |
6130 | in the elements of @var{vector}. @samp{List->vector} returns a newly | |
6131 | created vector initialized to the elements of the list @var{list}. | |
6132 | ||
6133 | ||
6134 | @format | |
6135 | @t{(vector->list '#(dah dah didah)) | |
6136 | ==> (dah dah didah) | |
6137 | (list->vector '(dididit dah)) | |
6138 | ==> #(dididit dah) | |
6139 | } | |
6140 | @end format | |
6141 | ||
6142 | @end deffn | |
6143 | ||
6144 | ||
6145 | ||
6146 | @deffn {library procedure} vector-fill! vector fill | |
6147 | ||
6148 | Stores @var{fill} in every element of @var{vector}. | |
6149 | The value returned by @samp{vector-fill!} is unspecified. | |
6150 | @c <!> | |
6151 | ||
6152 | @end deffn | |
6153 | ||
6154 | ||
6155 | @node Control features, Eval, Other data types, Standard procedures | |
6156 | @section Control features | |
6157 | ||
6158 | ||
6159 | ||
6160 | @c Intro flushed; not very a propos any more. | |
6161 | @c Procedures should be discussed somewhere, however. | |
6162 | ||
6163 | This chapter describes various primitive procedures which control the | |
6164 | flow of program execution in special ways. | |
6165 | The @samp{procedure?} predicate is also described here. | |
6166 | ||
6167 | @ignore todo | |
6168 | @t{Procedure?} doesn't belong in a section with the name | |
6169 | ``control features.'' What to do? | |
6170 | @end ignore | |
6171 | ||
6172 | ||
6173 | ||
6174 | @deffn {procedure} procedure? obj | |
6175 | ||
6176 | Returns @t{#t} if @var{obj} is a procedure, otherwise returns @t{#f}. | |
6177 | ||
6178 | ||
6179 | @format | |
6180 | @t{(procedure? car) ==> #t | |
6181 | (procedure? 'car) ==> #f | |
6182 | (procedure? (lambda (x) (* x x))) | |
6183 | ==> #t | |
6184 | (procedure? '(lambda (x) (* x x))) | |
6185 | ==> #f | |
6186 | (call-with-current-continuation procedure?) | |
6187 | ==> #t | |
6188 | } | |
6189 | @end format | |
6190 | ||
6191 | ||
6192 | @end deffn | |
6193 | ||
6194 | ||
6195 | ||
6196 | @deffn {procedure} apply proc arg1 @dots{} args | |
6197 | ||
6198 | @var{Proc} must be a procedure and @var{args} must be a list. | |
6199 | Calls @var{proc} with the elements of the list | |
6200 | @samp{(append (list @var{arg1} @dots{},) @var{args})} as the actual | |
6201 | arguments. | |
6202 | ||
6203 | ||
6204 | @format | |
6205 | @t{(apply + (list 3 4)) ==> 7 | |
6206 | ||
6207 | (define compose | |
6208 | (lambda (f g) | |
6209 | (lambda args | |
6210 | (f (apply g args))))) | |
6211 | ||
6212 | ((compose sqrt *) 12 75) ==> 30 | |
6213 | } | |
6214 | @end format | |
6215 | ||
6216 | @end deffn | |
6217 | ||
6218 | ||
6219 | ||
6220 | @deffn {library procedure} map proc list1 list2 @dots{}, | |
6221 | ||
6222 | The @var{list}s must be lists, and @var{proc} must be a | |
6223 | procedure taking as many arguments as there are @i{list}s | |
6224 | and returning a single value. If more | |
6225 | than one @var{list} is given, then they must all be the same length. | |
6226 | @samp{Map} applies @var{proc} element-wise to the elements of the | |
6227 | @var{list}s and returns a list of the results, in order. | |
6228 | The dynamic order in which @var{proc} is applied to the elements of the | |
6229 | @var{list}s is unspecified. | |
6230 | ||
6231 | ||
6232 | @format | |
6233 | @t{(map cadr '((a b) (d e) (g h))) | |
6234 | ==> (b e h) | |
6235 | ||
6236 | (map (lambda (n) (expt n n)) | |
6237 | '(1 2 3 4 5)) | |
6238 | ==> (1 4 27 256 3125) | |
6239 | ||
6240 | (map + '(1 2 3) '(4 5 6)) ==> (5 7 9) | |
6241 | ||
6242 | (let ((count 0)) | |
6243 | (map (lambda (ignored) | |
6244 | (set! count (+ count 1)) | |
6245 | count) | |
6246 | '(a b))) ==> (1 2) @var{or} (2 1) | |
6247 | } | |
6248 | @end format | |
6249 | ||
6250 | ||
6251 | @end deffn | |
6252 | ||
6253 | ||
6254 | ||
6255 | @deffn {library procedure} for-each proc list1 list2 @dots{}, | |
6256 | ||
6257 | The arguments to @samp{for-each} are like the arguments to @samp{map}, but | |
6258 | @samp{for-each} calls @var{proc} for its side effects rather than for its | |
6259 | values. Unlike @samp{map}, @samp{for-each} is guaranteed to call @var{proc} on | |
6260 | the elements of the @var{list}s in order from the first element(s) to the | |
6261 | last, and the value returned by @samp{for-each} is unspecified. | |
6262 | ||
6263 | ||
6264 | @format | |
6265 | @t{(let ((v (make-vector 5))) | |
6266 | (for-each (lambda (i) | |
6267 | (vector-set! v i (* i i))) | |
6268 | '(0 1 2 3 4)) | |
6269 | v) ==> #(0 1 4 9 16) | |
6270 | } | |
6271 | @end format | |
6272 | ||
6273 | ||
6274 | @end deffn | |
6275 | ||
6276 | ||
6277 | ||
6278 | @deffn {library procedure} force promise | |
6279 | ||
6280 | Forces the value of @var{promise} (see @code{delay}, | |
6281 | @vindex @w{delay} | |
6282 | section @pxref{Delayed evaluation}). If no value has been computed for | |
6283 | @cindex @w{promise} | |
6284 | the promise, then a value is computed and returned. The value of the | |
6285 | promise is cached (or ``memoized'') so that if it is forced a second | |
6286 | time, the previously computed value is returned. | |
6287 | @c without any recomputation. | |
6288 | @c [As pointed out by Marc Feeley, the "without any recomputation" | |
6289 | @c isn't necessarily true. --Will] | |
6290 | ||
6291 | ||
6292 | @format | |
6293 | @t{(force (delay (+ 1 2))) ==> 3 | |
6294 | (let ((p (delay (+ 1 2)))) | |
6295 | (list (force p) (force p))) | |
6296 | ==> (3 3) | |
6297 | ||
6298 | (define a-stream | |
6299 | (letrec ((next | |
6300 | (lambda (n) | |
6301 | (cons n (delay (next (+ n 1))))))) | |
6302 | (next 0))) | |
6303 | (define head car) | |
6304 | (define tail | |
6305 | (lambda (stream) (force (cdr stream)))) | |
6306 | ||
6307 | (head (tail (tail a-stream))) | |
6308 | ==> 2 | |
6309 | } | |
6310 | @end format | |
6311 | ||
6312 | ||
6313 | @samp{Force} and @samp{delay} are mainly intended for programs written in | |
6314 | functional style. The following examples should not be considered to | |
6315 | illustrate good programming style, but they illustrate the property that | |
6316 | only one value is computed for a promise, no matter how many times it is | |
6317 | forced. | |
6318 | @c the value of a promise is computed at most once. | |
6319 | @c [As pointed out by Marc Feeley, it may be computed more than once, | |
6320 | @c but as I observed we can at least insist that only one value be | |
6321 | @c used! -- Will] | |
6322 | ||
6323 | ||
6324 | @format | |
6325 | @t{(define count 0) | |
6326 | (define p | |
6327 | (delay (begin (set! count (+ count 1)) | |
6328 | (if (> count x) | |
6329 | count | |
6330 | (force p))))) | |
6331 | (define x 5) | |
6332 | p ==> @i{}a promise | |
6333 | (force p) ==> 6 | |
6334 | p ==> @i{}a promise, still | |
6335 | (begin (set! x 10) | |
6336 | (force p)) ==> 6 | |
6337 | } | |
6338 | @end format | |
6339 | ||
6340 | ||
6341 | Here is a possible implementation of @samp{delay} and @samp{force}. | |
6342 | Promises are implemented here as procedures of no arguments, | |
6343 | and @samp{force} simply calls its argument: | |
6344 | ||
6345 | ||
6346 | @format | |
6347 | @t{(define force | |
6348 | (lambda (object) | |
6349 | (object))) | |
6350 | } | |
6351 | @end format | |
6352 | ||
6353 | ||
6354 | We define the expression | |
6355 | ||
6356 | ||
6357 | @format | |
6358 | @t{(delay @r{<expression>}) | |
6359 | } | |
6360 | @end format | |
6361 | ||
6362 | ||
6363 | to have the same meaning as the procedure call | |
6364 | ||
6365 | ||
6366 | @format | |
6367 | @t{(make-promise (lambda () @r{<expression>}))@r{} | |
6368 | } | |
6369 | @end format | |
6370 | ||
6371 | ||
6372 | as follows | |
6373 | ||
6374 | ||
6375 | @format | |
6376 | @t{(define-syntax delay | |
6377 | (syntax-rules () | |
6378 | ((delay expression) | |
6379 | (make-promise (lambda () expression))))), | |
6380 | } | |
6381 | @end format | |
6382 | ||
6383 | ||
6384 | where @samp{make-promise} is defined as follows: | |
6385 | ||
6386 | @c \begin{scheme} | |
6387 | @c (define make-promise | |
6388 | @c (lambda (proc) | |
6389 | @c (let ((already-run? \schfalse) (result \schfalse)) | |
6390 | @c (lambda () | |
6391 | @c (cond ((not already-run?) | |
6392 | @c (set! result (proc)) | |
6393 | @c (set! already-run? \schtrue))) | |
6394 | @c result))))% | |
6395 | @c \end{scheme} | |
6396 | ||
6397 | ||
6398 | @format | |
6399 | @t{(define make-promise | |
6400 | (lambda (proc) | |
6401 | (let ((result-ready? #f) | |
6402 | (result #f)) | |
6403 | (lambda () | |
6404 | (if result-ready? | |
6405 | result | |
6406 | (let ((x (proc))) | |
6407 | (if result-ready? | |
6408 | result | |
6409 | (begin (set! result-ready? #t) | |
6410 | (set! result x) | |
6411 | result)))))))) | |
6412 | } | |
6413 | @end format | |
6414 | ||
6415 | ||
6416 | ||
6417 | @quotation | |
6418 | @emph{Rationale:} | |
6419 | A promise may refer to its own value, as in the last example above. | |
6420 | Forcing such a promise may cause the promise to be forced a second time | |
6421 | before the value of the first force has been computed. | |
6422 | This complicates the definition of @samp{make-promise}. | |
6423 | @end quotation | |
6424 | ||
6425 | ||
6426 | Various extensions to this semantics of @samp{delay} and @samp{force} | |
6427 | are supported in some implementations: | |
6428 | ||
6429 | ||
6430 | ||
6431 | @itemize @bullet | |
6432 | ||
6433 | @item | |
6434 | Calling @samp{force} on an object that is not a promise may simply | |
6435 | return the object. | |
6436 | ||
6437 | @item | |
6438 | It may be the case that there is no means by which a promise can be | |
6439 | operationally distinguished from its forced value. That is, expressions | |
6440 | like the following may evaluate to either @t{#t} or to @t{#f}, | |
6441 | depending on the implementation: | |
6442 | ||
6443 | ||
6444 | @format | |
6445 | @t{(eqv? (delay 1) 1) ==> @emph{unspecified} | |
6446 | (pair? (delay (cons 1 2))) ==> @emph{unspecified} | |
6447 | } | |
6448 | @end format | |
6449 | ||
6450 | ||
6451 | @item | |
6452 | Some implementations may implement ``implicit forcing,'' where | |
6453 | the value of a promise is forced by primitive procedures like @samp{cdr} | |
6454 | and @samp{+}: | |
6455 | ||
6456 | ||
6457 | @format | |
6458 | @t{(+ (delay (* 3 7)) 13) ==> 34 | |
6459 | } | |
6460 | @end format | |
6461 | ||
6462 | ||
6463 | @end itemize | |
6464 | ||
6465 | @end deffn | |
6466 | ||
6467 | ||
6468 | @deffn {procedure} call-with-current-continuation proc | |
6469 | ||
6470 | @var{Proc} must be a procedure of one | |
6471 | argument. The procedure @samp{call-with-current-continuation} packages | |
6472 | up the current continuation (see the rationale below) as an ``escape | |
6473 | procedure'' and passes it as an argument to | |
6474 | @cindex @w{escape procedure} | |
6475 | @var{proc}. The escape procedure is a Scheme procedure that, if it is | |
6476 | later called, will abandon whatever continuation is in effect at that later | |
6477 | time and will instead use the continuation that was in effect | |
6478 | when the escape procedure was created. Calling the escape procedure | |
6479 | may cause the invocation of @var{before} and @var{after} thunks installed using | |
6480 | @code{dynamic-wind}. | |
6481 | @vindex @w{dynamic-wind} | |
6482 | ||
6483 | The escape procedure accepts the same number of arguments as the continuation to | |
6484 | the original call to @t{call-with-current-continuation}. | |
6485 | Except for continuations created by the @samp{call-with-values} | |
6486 | procedure, all continuations take exactly one value. The | |
6487 | effect of passing no value or more than one value to continuations | |
6488 | that were not created by @t{call-with-values} is unspecified. | |
6489 | ||
6490 | The escape procedure that is passed to @var{proc} has | |
6491 | unlimited extent just like any other procedure in Scheme. It may be stored | |
6492 | in variables or data structures and may be called as many times as desired. | |
6493 | ||
6494 | The following examples show only the most common ways in which | |
6495 | @samp{call-with-current-continuation} is used. If all real uses were as | |
6496 | simple as these examples, there would be no need for a procedure with | |
6497 | the power of @samp{call-with-current-continuation}. | |
6498 | ||
6499 | ||
6500 | @format | |
6501 | @t{(call-with-current-continuation | |
6502 | (lambda (exit) | |
6503 | (for-each (lambda (x) | |
6504 | (if (negative? x) | |
6505 | (exit x))) | |
6506 | '(54 0 37 -3 245 19)) | |
6507 | #t)) ==> -3 | |
6508 | ||
6509 | (define list-length | |
6510 | (lambda (obj) | |
6511 | (call-with-current-continuation | |
6512 | (lambda (return) | |
6513 | (letrec ((r | |
6514 | (lambda (obj) | |
6515 | (cond ((null? obj) 0) | |
6516 | ((pair? obj) | |
6517 | (+ (r (cdr obj)) 1)) | |
6518 | (else (return #f)))))) | |
6519 | (r obj)))))) | |
6520 | ||
6521 | (list-length '(1 2 3 4)) ==> 4 | |
6522 | ||
6523 | (list-length '(a b . c)) ==> #f | |
6524 | } | |
6525 | @end format | |
6526 | ||
6527 | ||
6528 | ||
6529 | @quotation | |
6530 | @emph{Rationale:} | |
6531 | ||
6532 | A common use of @samp{call-with-current-continuation} is for | |
6533 | structured, non-local exits from loops or procedure bodies, but in fact | |
6534 | @samp{call-with-current-continuation} is extremely useful for implementing a | |
6535 | wide variety of advanced control structures. | |
6536 | ||
6537 | Whenever a Scheme expression is evaluated there is a | |
6538 | @dfn{continuation} wanting the result of the expression. The continuation | |
6539 | @cindex @w{continuation} | |
6540 | represents an entire (default) future for the computation. If the expression is | |
6541 | evaluated at top level, for example, then the continuation might take the | |
6542 | result, print it on the screen, prompt for the next input, evaluate it, and | |
6543 | so on forever. Most of the time the continuation includes actions | |
6544 | specified by user code, as in a continuation that will take the result, | |
6545 | multiply it by the value stored in a local variable, add seven, and give | |
6546 | the answer to the top level continuation to be printed. Normally these | |
6547 | ubiquitous continuations are hidden behind the scenes and programmers do not | |
6548 | think much about them. On rare occasions, however, a programmer may | |
6549 | need to deal with continuations explicitly. | |
6550 | @samp{Call-with-current-continuation} allows Scheme programmers to do | |
6551 | that by creating a procedure that acts just like the current | |
6552 | continuation. | |
6553 | ||
6554 | Most programming languages incorporate one or more special-purpose | |
6555 | escape constructs with names like @t{exit}, @w{@samp{return}}, or | |
6556 | even @t{goto}. In 1965, however, Peter Landin [Landin65] | |
6557 | invented a general purpose escape operator called the J-operator. John | |
6558 | Reynolds [Reynolds72] described a simpler but equally powerful | |
6559 | construct in 1972. The @samp{catch} special form described by Sussman | |
6560 | and Steele in the 1975 report on Scheme is exactly the same as | |
6561 | Reynolds's construct, though its name came from a less general construct | |
6562 | in MacLisp. Several Scheme implementors noticed that the full power of the | |
6563 | @code{catch} construct could be provided by a procedure instead of by a | |
6564 | @vindex @w{catch} | |
6565 | special syntactic construct, and the name | |
6566 | @samp{call-with-current-continuation} was coined in 1982. This name is | |
6567 | descriptive, but opinions differ on the merits of such a long name, and | |
6568 | some people use the name @code{call/cc} instead. | |
6569 | @vindex @w{call/cc} | |
6570 | @end quotation | |
6571 | ||
6572 | ||
6573 | @end deffn | |
6574 | ||
6575 | ||
6576 | @deffn {procedure} values obj @dots{} | |
6577 | ||
6578 | Delivers all of its arguments to its continuation. | |
6579 | Except for continuations created by the @code{call-with-values} | |
6580 | @vindex @w{call-with-values} | |
6581 | procedure, all continuations take exactly one value. | |
6582 | @t{Values} might be defined as follows: | |
6583 | ||
6584 | @format | |
6585 | @t{(define (values . things) | |
6586 | (call-with-current-continuation | |
6587 | (lambda (cont) (apply cont things)))) | |
6588 | } | |
6589 | @end format | |
6590 | ||
6591 | ||
6592 | @end deffn | |
6593 | ||
6594 | ||
6595 | @deffn {procedure} call-with-values producer consumer | |
6596 | ||
6597 | Calls its @var{producer} argument with no values and | |
6598 | a continuation that, when passed some values, calls the | |
6599 | @var{consumer} procedure with those values as arguments. | |
6600 | The continuation for the call to @var{consumer} is the | |
6601 | continuation of the call to @t{call-with-values}. | |
6602 | ||
6603 | ||
6604 | @format | |
6605 | @t{(call-with-values (lambda () (values 4 5)) | |
6606 | (lambda (a b) b)) | |
6607 | ==> 5 | |
6608 | ||
6609 | (call-with-values * -) ==> -1 | |
6610 | } | |
6611 | @end format | |
6612 | ||
6613 | ||
6614 | @end deffn | |
6615 | ||
6616 | ||
6617 | @deffn {procedure} dynamic-wind before thunk after | |
6618 | ||
6619 | Calls @var{thunk} without arguments, returning the result(s) of this call. | |
6620 | @var{Before} and @var{after} are called, also without arguments, as required | |
6621 | by the following rules (note that in the absence of calls to continuations | |
6622 | captured using @code{call-with-current-continuation} the three arguments are | |
6623 | @vindex @w{call-with-current-continuation} | |
6624 | called once each, in order). @var{Before} is called whenever execution | |
6625 | enters the dynamic extent of the call to @var{thunk} and @var{after} is called | |
6626 | whenever it exits that dynamic extent. The dynamic extent of a procedure | |
6627 | call is the period between when the call is initiated and when it | |
6628 | returns. In Scheme, because of @samp{call-with-current-continuation}, the | |
6629 | dynamic extent of a call may not be a single, connected time period. | |
6630 | It is defined as follows: | |
6631 | ||
6632 | ||
6633 | @itemize @bullet | |
6634 | ||
6635 | @item | |
6636 | The dynamic extent is entered when execution of the body of the | |
6637 | called procedure begins. | |
6638 | ||
6639 | @item | |
6640 | The dynamic extent is also entered when execution is not within | |
6641 | the dynamic extent and a continuation is invoked that was captured | |
6642 | (using @samp{call-with-current-continuation}) during the dynamic extent. | |
6643 | ||
6644 | @item | |
6645 | It is exited when the called procedure returns. | |
6646 | ||
6647 | @item | |
6648 | It is also exited when execution is within the dynamic extent and | |
6649 | a continuation is invoked that was captured while not within the | |
6650 | dynamic extent. | |
6651 | ||
6652 | @end itemize | |
6653 | ||
6654 | ||
6655 | If a second call to @samp{dynamic-wind} occurs within the dynamic extent of the | |
6656 | call to @var{thunk} and then a continuation is invoked in such a way that the | |
6657 | @var{after}s from these two invocations of @samp{dynamic-wind} are both to be | |
6658 | called, then the @var{after} associated with the second (inner) call to | |
6659 | @samp{dynamic-wind} is called first. | |
6660 | ||
6661 | If a second call to @samp{dynamic-wind} occurs within the dynamic extent of the | |
6662 | call to @var{thunk} and then a continuation is invoked in such a way that the | |
6663 | @var{before}s from these two invocations of @samp{dynamic-wind} are both to be | |
6664 | called, then the @var{before} associated with the first (outer) call to | |
6665 | @samp{dynamic-wind} is called first. | |
6666 | ||
6667 | If invoking a continuation requires calling the @var{before} from one call | |
6668 | to @samp{dynamic-wind} and the @var{after} from another, then the @var{after} | |
6669 | is called first. | |
6670 | ||
6671 | The effect of using a captured continuation to enter or exit the dynamic | |
6672 | extent of a call to @var{before} or @var{after} is undefined. | |
6673 | ||
6674 | ||
6675 | @format | |
6676 | @t{(let ((path '()) | |
6677 | (c #f)) | |
6678 | (let ((add (lambda (s) | |
6679 | (set! path (cons s path))))) | |
6680 | (dynamic-wind | |
6681 | (lambda () (add 'connect)) | |
6682 | (lambda () | |
6683 | (add (call-with-current-continuation | |
6684 | (lambda (c0) | |
6685 | (set! c c0) | |
6686 | 'talk1)))) | |
6687 | (lambda () (add 'disconnect))) | |
6688 | (if (< (length path) 4) | |
6689 | (c 'talk2) | |
6690 | (reverse path)))) | |
6691 | ||
6692 | ==> (connect talk1 disconnect | |
6693 | connect talk2 disconnect) | |
6694 | } | |
6695 | @end format | |
6696 | ||
6697 | @end deffn | |
6698 | ||
6699 | @node Eval, Input and output, Control features, Standard procedures | |
6700 | @section Eval | |
6701 | ||
6702 | ||
6703 | ||
6704 | @deffn {procedure} eval expression environment-specifier | |
6705 | ||
6706 | Evaluates @var{expression} in the specified environment and returns its value. | |
6707 | @var{Expression} must be a valid Scheme expression represented as data, | |
6708 | and @var{environment-specifier} must be a value returned by one of the | |
6709 | three procedures described below. | |
6710 | Implementations may extend @samp{eval} to allow non-expression programs | |
6711 | (definitions) as the first argument and to allow other | |
6712 | values as environments, with the restriction that @samp{eval} is not | |
6713 | allowed to create new bindings in the environments associated with | |
6714 | @samp{null-environment} or @samp{scheme-report-environment}. | |
6715 | ||
6716 | ||
6717 | @format | |
6718 | @t{(eval '(* 7 3) (scheme-report-environment 5)) | |
6719 | ==> 21 | |
6720 | ||
6721 | (let ((f (eval '(lambda (f x) (f x x)) | |
6722 | (null-environment 5)))) | |
6723 | (f + 10)) | |
6724 | ==> 20 | |
6725 | } | |
6726 | @end format | |
6727 | ||
6728 | ||
6729 | @end deffn | |
6730 | ||
6731 | ||
6732 | @deffn {procedure} scheme-report-environment version | |
6733 | @deffnx {procedure} null-environment version | |
6734 | ||
6735 | @var{Version} must be the exact integer @samp{5}, | |
6736 | corresponding to this revision of the Scheme report (the | |
6737 | Revised^5 Report on Scheme). | |
6738 | @samp{Scheme-report-environment} returns a specifier for an | |
6739 | environment that is empty except for all bindings defined in | |
6740 | this report that are either required or both optional and | |
6741 | supported by the implementation. @samp{Null-environment} returns | |
6742 | a specifier for an environment that is empty except for the | |
6743 | (syntactic) bindings for all syntactic keywords defined in | |
6744 | this report that are either required or both optional and | |
6745 | supported by the implementation. | |
6746 | ||
6747 | Other values of @var{version} can be used to specify environments | |
6748 | matching past revisions of this report, but their support is not | |
6749 | required. An implementation will signal an error if @var{version} | |
6750 | is neither @samp{5} nor another value supported by | |
6751 | the implementation. | |
6752 | ||
6753 | The effect of assigning (through the use of @samp{eval}) a variable | |
6754 | bound in a @samp{scheme-report-environment} | |
6755 | (for example @samp{car}) is unspecified. Thus the environments specified | |
6756 | by @samp{scheme-report-environment} may be immutable. | |
6757 | ||
6758 | @end deffn | |
6759 | ||
6760 | ||
6761 | @deffn {optional procedure} interaction-environment | |
6762 | ||
6763 | This procedure returns a specifier for the environment that | |
6764 | contains imple@-men@-ta@-tion-defined bindings, typically a superset of | |
6765 | those listed in the report. The intent is that this procedure | |
6766 | will return the environment in which the implementation would evaluate | |
6767 | expressions dynamically typed by the user. | |
6768 | ||
6769 | @end deffn | |
6770 | ||
6771 | @node Input and output, , Eval, Standard procedures | |
6772 | @section Input and output | |
6773 | ||
6774 | @menu | |
6775 | * Ports:: | |
6776 | * Input:: | |
6777 | * Output:: | |
6778 | * System interface:: | |
6779 | @end menu | |
6780 | ||
6781 | ||
6782 | @node Ports, Input, Input and output, Input and output | |
6783 | @subsection Ports | |
6784 | ||
6785 | ||
6786 | ||
6787 | Ports represent input and output devices. To Scheme, an input port is a | |
6788 | Scheme object that can deliver characters upon command, while an output port | |
6789 | is a Scheme object that can accept characters. | |
6790 | @cindex @w{port} | |
6791 | ||
6792 | @ignore todo | |
6793 | Haase: Mention that there are alternatives to files? | |
6794 | @end ignore | |
6795 | ||
6796 | ||
6797 | ||
6798 | @deffn {library procedure} call-with-input-file string proc | |
6799 | @deffnx {library procedure} call-with-output-file string proc | |
6800 | ||
6801 | @var{String} should be a string naming a file, and | |
6802 | @var{proc} should be a procedure that accepts one argument. | |
6803 | For @samp{call-with-input-file}, | |
6804 | the file should already exist; for | |
6805 | @samp{call-with-output-file}, | |
6806 | the effect is unspecified if the file | |
6807 | already exists. These procedures call @var{proc} with one argument: the | |
6808 | port obtained by opening the named file for input or output. If the | |
6809 | file cannot be opened, an error is signalled. If @var{proc} returns, | |
6810 | then the port is closed automatically and the value(s) yielded by the | |
6811 | @var{proc} is(are) returned. If @var{proc} does not return, then | |
6812 | the port will not be closed automatically unless it is possible to | |
6813 | prove that the port will never again be used for a read or write | |
6814 | operation. | |
6815 | @c Scheme | |
6816 | @c will not close the port unless it can prove that the port will never | |
6817 | @c again be used for a read or write operation. | |
6818 | ||
6819 | ||
6820 | @quotation | |
6821 | @emph{Rationale:} | |
6822 | Because Scheme's escape procedures have unlimited extent, it is | |
6823 | possible to escape from the current continuation but later to escape back in. | |
6824 | If implementations were permitted to close the port on any escape from the | |
6825 | current continuation, then it would be impossible to write portable code using | |
6826 | both @samp{call-with-current-continuation} and @samp{call-with-input-file} or | |
6827 | @samp{call-with-output-file}. | |
6828 | @ignore todo | |
6829 | Pitman wants more said here; maybe encourage users to call | |
6830 | @var{close-foo-port}; maybe talk about process switches (?). | |
6831 | @end ignore | |
6832 | ||
6833 | @end quotation | |
6834 | ||
6835 | @end deffn | |
6836 | ||
6837 | ||
6838 | ||
6839 | @deffn {procedure} input-port? obj | |
6840 | @deffnx {procedure} output-port? obj | |
6841 | ||
6842 | Returns @t{#t} if @var{obj} is an input port or output port | |
6843 | respectively, otherwise returns @t{#f}. | |
6844 | ||
6845 | @ignore todo | |
6846 | Won't necessarily return true after port is closed. | |
6847 | @end ignore | |
6848 | ||
6849 | ||
6850 | @end deffn | |
6851 | ||
6852 | ||
6853 | ||
6854 | @deffn {procedure} current-input-port | |
6855 | @deffnx {procedure} current-output-port | |
6856 | ||
6857 | Returns the current default input or output port. | |
6858 | ||
6859 | @end deffn | |
6860 | ||
6861 | ||
6862 | ||
6863 | @deffn {optional procedure} with-input-from-file string thunk | |
6864 | @deffnx {optional procedure} with-output-to-file string thunk | |
6865 | ||
6866 | @var{String} should be a string naming a file, and | |
6867 | @var{proc} should be a procedure of no arguments. | |
6868 | For @samp{with-input-from-file}, | |
6869 | the file should already exist; for | |
6870 | @samp{with-output-to-file}, | |
6871 | the effect is unspecified if the file | |
6872 | already exists. | |
6873 | The file is opened for input or output, an input or output port | |
6874 | connected to it is made the default value returned by | |
6875 | @samp{current-input-port} or @samp{current-output-port} | |
6876 | (and is used by @t{(read)}, @t{(write @var{obj})}, and so forth), | |
6877 | and the | |
6878 | @var{thunk} is called with no arguments. When the @var{thunk} returns, | |
6879 | the port is closed and the previous default is restored. | |
6880 | @samp{With-input-from-file} and @samp{with-output-to-file} return(s) the | |
6881 | value(s) yielded by @var{thunk}. | |
6882 | If an escape procedure | |
6883 | is used to escape from the continuation of these procedures, their | |
6884 | behavior is implementation dependent. | |
6885 | ||
6886 | @ignore todo | |
6887 | OK this with authors?? | |
6888 | @end ignore | |
6889 | ||
6890 | @c current continuation changes in such a way | |
6891 | @c as to make it doubtful that the \var{thunk} will ever return. | |
6892 | ||
6893 | @ignore todo | |
6894 | Freeman: | |
6895 | Throughout this section I wanted to see ``the value of @t{(current-input-port)}'' | |
6896 | instead of ``the value returned by @var{current-input-port}''. (Same for | |
6897 | @var{current-output-port}.) | |
6898 | @end ignore | |
6899 | ||
6900 | ||
6901 | ||
6902 | @end deffn | |
6903 | ||
6904 | ||
6905 | ||
6906 | @deffn {procedure} open-input-file filename | |
6907 | ||
6908 | Takes a string naming an existing file and returns an input port capable of | |
6909 | delivering characters from the file. If the file cannot be opened, an error is | |
6910 | signalled. | |
6911 | ||
6912 | @end deffn | |
6913 | ||
6914 | ||
6915 | ||
6916 | @deffn {procedure} open-output-file filename | |
6917 | ||
6918 | Takes a string naming an output file to be created and returns an output | |
6919 | port capable of writing characters to a new file by that name. If the file | |
6920 | cannot be opened, an error is signalled. If a file with the given name | |
6921 | already exists, the effect is unspecified. | |
6922 | ||
6923 | @end deffn | |
6924 | ||
6925 | ||
6926 | ||
6927 | @deffn {procedure} close-input-port port | |
6928 | @deffnx {procedure} close-output-port port | |
6929 | ||
6930 | Closes the file associated with @var{port}, rendering the @var{port} | |
6931 | incapable of delivering or accepting characters. | |
6932 | @ignore todo | |
6933 | But maybe a no-op | |
6934 | on some ports, e.g. terminals or editor buffers. | |
6935 | @end ignore | |
6936 | ||
6937 | These routines have no effect if the file has already been closed. | |
6938 | The value returned is unspecified. | |
6939 | ||
6940 | @ignore todo | |
6941 | Ramsdell: Some note is needed explaining why there are two | |
6942 | different close procedures. | |
6943 | @end ignore | |
6944 | ||
6945 | ||
6946 | @ignore todo | |
6947 | A port isn't necessarily still a port after it has been closed? | |
6948 | @end ignore | |
6949 | ||
6950 | ||
6951 | @end deffn | |
6952 | ||
6953 | ||
6954 | @node Input, Output, Ports, Input and output | |
6955 | @subsection Input | |
6956 | ||
6957 | ||
6958 | ||
6959 | ||
6960 | @noindent | |
6961 | @w{ } | |
6962 | @c ??? | |
6963 | @sp 5 | |
6964 | @ignore todo | |
6965 | The input routines have some things in common, maybe explain here. | |
6966 | @end ignore | |
6967 | ||
6968 | ||
6969 | ||
6970 | @deffn {library procedure} read | |
6971 | @deffnx {library procedure} read port | |
6972 | ||
6973 | @samp{Read} converts external representations of Scheme objects into the | |
6974 | objects themselves. That is, it is a parser for the nonterminal | |
6975 | <datum> (see sections @pxref{External representation} and | |
6976 | @pxref{Pairs and lists}). @samp{Read} returns the next | |
6977 | object parsable from the given input @var{port}, updating @var{port} to point to | |
6978 | the first character past the end of the external representation of the object. | |
6979 | ||
6980 | If an end of file is encountered in the input before any | |
6981 | characters are found that can begin an object, then an end of file | |
6982 | object is returned. | |
6983 | @ignore todo | |
6984 | ||
6985 | @end ignore | |
6986 | The port remains open, and further attempts | |
6987 | to read will also return an end of file object. If an end of file is | |
6988 | encountered after the beginning of an object's external representation, | |
6989 | but the external representation is incomplete and therefore not parsable, | |
6990 | an error is signalled. | |
6991 | ||
6992 | The @var{port} argument may be omitted, in which case it defaults to the | |
6993 | value returned by @samp{current-input-port}. It is an error to read from | |
6994 | a closed port. | |
6995 | @end deffn | |
6996 | ||
6997 | ||
6998 | @deffn {procedure} read-char | |
6999 | @deffnx {procedure} read-char port | |
7000 | ||
7001 | Returns the next character available from the input @var{port}, updating | |
7002 | the @var{port} to point to the following character. If no more characters | |
7003 | are available, an end of file object is returned. @var{Port} may be | |
7004 | omitted, in which case it defaults to the value returned by @samp{current-input-port}. | |
7005 | ||
7006 | @end deffn | |
7007 | ||
7008 | ||
7009 | ||
7010 | @deffn {procedure} peek-char | |
7011 | @deffnx {procedure} peek-char port | |
7012 | ||
7013 | Returns the next character available from the input @var{port}, | |
7014 | @emph{without} updating | |
7015 | the @var{port} to point to the following character. If no more characters | |
7016 | are available, an end of file object is returned. @var{Port} may be | |
7017 | omitted, in which case it defaults to the value returned by @samp{current-input-port}. | |
7018 | ||
7019 | ||
7020 | @quotation | |
7021 | @emph{Note:} | |
7022 | The value returned by a call to @samp{peek-char} is the same as the | |
7023 | value that would have been returned by a call to @samp{read-char} with the | |
7024 | same @var{port}. The only difference is that the very next call to | |
7025 | @samp{read-char} or @samp{peek-char} on that @var{port} will return the | |
7026 | value returned by the preceding call to @samp{peek-char}. In particular, a call | |
7027 | to @samp{peek-char} on an interactive port will hang waiting for input | |
7028 | whenever a call to @samp{read-char} would have hung. | |
7029 | @end quotation | |
7030 | ||
7031 | ||
7032 | @end deffn | |
7033 | ||
7034 | ||
7035 | ||
7036 | @deffn {procedure} eof-object? obj | |
7037 | ||
7038 | Returns @t{#t} if @var{obj} is an end of file object, otherwise returns | |
7039 | @t{#f}. The precise set of end of file objects will vary among | |
7040 | implementations, but in any case no end of file object will ever be an object | |
7041 | that can be read in using @samp{read}. | |
7042 | ||
7043 | @end deffn | |
7044 | ||
7045 | ||
7046 | ||
7047 | @deffn {procedure} char-ready? | |
7048 | @deffnx {procedure} char-ready? port | |
7049 | ||
7050 | Returns @t{#t} if a character is ready on the input @var{port} and | |
7051 | returns @t{#f} otherwise. If @samp{char-ready} returns @t{#t} then | |
7052 | the next @samp{read-char} operation on the given @var{port} is guaranteed | |
7053 | not to hang. If the @var{port} is at end of file then @samp{char-ready?} | |
7054 | returns @t{#t}. @var{Port} may be omitted, in which case it defaults to | |
7055 | the value returned by @samp{current-input-port}. | |
7056 | ||
7057 | ||
7058 | @quotation | |
7059 | @emph{Rationale:} | |
7060 | @samp{Char-ready?} exists to make it possible for a program to | |
7061 | accept characters from interactive ports without getting stuck waiting for | |
7062 | input. Any input editors associated with such ports must ensure that | |
7063 | characters whose existence has been asserted by @samp{char-ready?} cannot | |
7064 | be rubbed out. If @samp{char-ready?} were to return @t{#f} at end of | |
7065 | file, a port at end of file would be indistinguishable from an interactive | |
7066 | port that has no ready characters. | |
7067 | @end quotation | |
7068 | ||
7069 | @end deffn | |
7070 | ||
7071 | ||
7072 | @node Output, System interface, Input, Input and output | |
7073 | @subsection Output | |
7074 | ||
7075 | ||
7076 | ||
7077 | @c We've got to put something here to fix the indentation!! | |
7078 | ||
7079 | @noindent | |
7080 | @w{} | |
7081 | @sp 5 | |
7082 | ||
7083 | ||
7084 | @deffn {library procedure} write obj | |
7085 | @deffnx {library procedure} write obj port | |
7086 | ||
7087 | Writes a written representation of @var{obj} to the given @var{port}. Strings | |
7088 | that appear in the written representation are enclosed in doublequotes, and | |
7089 | within those strings backslash and doublequote characters are | |
7090 | escaped by backslashes. | |
7091 | Character objects are written using the @samp{#\} notation. | |
7092 | @samp{Write} returns an unspecified value. The | |
7093 | @var{port} argument may be omitted, in which case it defaults to the value | |
7094 | returned by @samp{current-output-port}. | |
7095 | ||
7096 | @end deffn | |
7097 | ||
7098 | ||
7099 | ||
7100 | @deffn {library procedure} display obj | |
7101 | @deffnx {library procedure} display obj port | |
7102 | ||
7103 | Writes a representation of @var{obj} to the given @var{port}. Strings | |
7104 | that appear in the written representation are not enclosed in | |
7105 | doublequotes, and no characters are escaped within those strings. Character | |
7106 | objects appear in the representation as if written by @samp{write-char} | |
7107 | instead of by @samp{write}. @samp{Display} returns an unspecified value. | |
7108 | The @var{port} argument may be omitted, in which case it defaults to the | |
7109 | value returned by @samp{current-output-port}. | |
7110 | ||
7111 | ||
7112 | @quotation | |
7113 | @emph{Rationale:} | |
7114 | @samp{Write} is intended | |
7115 | for producing mach@-ine-readable output and @samp{display} is for producing | |
7116 | human-readable output. Implementations that allow ``slashification'' | |
7117 | within symbols will probably want @samp{write} but not @samp{display} to | |
7118 | slashify funny characters in symbols. | |
7119 | @end quotation | |
7120 | ||
7121 | @end deffn | |
7122 | ||
7123 | ||
7124 | ||
7125 | @deffn {library procedure} newline | |
7126 | @deffnx {library procedure} newline port | |
7127 | ||
7128 | Writes an end of line to @var{port}. Exactly how this is done differs | |
7129 | from one operating system to another. Returns an unspecified value. | |
7130 | The @var{port} argument may be omitted, in which case it defaults to the | |
7131 | value returned by @samp{current-output-port}. | |
7132 | ||
7133 | @end deffn | |
7134 | ||
7135 | ||
7136 | ||
7137 | @deffn {procedure} write-char char | |
7138 | @deffnx {procedure} write-char char port | |
7139 | ||
7140 | Writes the character @var{char} (not an external representation of the | |
7141 | character) to the given @var{port} and returns an unspecified value. The | |
7142 | @var{port} argument may be omitted, in which case it defaults to the value | |
7143 | returned by @samp{current-output-port}. | |
7144 | ||
7145 | @end deffn | |
7146 | ||
7147 | ||
7148 | @node System interface, , Output, Input and output | |
7149 | @subsection System interface | |
7150 | ||
7151 | ||
7152 | Questions of system interface generally fall outside of the domain of this | |
7153 | report. However, the following operations are important enough to | |
7154 | deserve description here. | |
7155 | ||
7156 | ||
7157 | ||
7158 | @deffn {optional procedure} load filename | |
7159 | ||
7160 | @ignore todo | |
7161 | Fix | |
7162 | @end ignore | |
7163 | ||
7164 | ||
7165 | @c \domain{\var{Filename} should be a string naming an existing file | |
7166 | @c containing Scheme source code.} The {\cf load} procedure reads | |
7167 | @var{Filename} should be a string naming an existing file | |
7168 | containing Scheme source code. The @samp{load} procedure reads | |
7169 | expressions and definitions from the file and evaluates them | |
7170 | sequentially. It is unspecified whether the results of the expressions | |
7171 | are printed. The @samp{load} procedure does not affect the values | |
7172 | returned by @samp{current-input-port} and @samp{current-output-port}. | |
7173 | @samp{Load} returns an unspecified value. | |
7174 | ||
7175 | ||
7176 | @quotation | |
7177 | @emph{Rationale:} | |
7178 | For portability, @samp{load} must operate on source files. | |
7179 | Its operation on other kinds of files necessarily varies among | |
7180 | implementations. | |
7181 | @end quotation | |
7182 | ||
7183 | @end deffn | |
7184 | ||
7185 | ||
7186 | ||
7187 | @deffn {optional procedure} transcript-on filename | |
7188 | @deffnx {optional procedure} transcript-off | |
7189 | ||
7190 | @var{Filename} must be a string naming an output file to be | |
7191 | created. The effect of @samp{transcript-on} is to open the named file | |
7192 | for output, and to cause a transcript of subsequent interaction between | |
7193 | the user and the Scheme system to be written to the file. The | |
7194 | transcript is ended by a call to @samp{transcript-off}, which closes the | |
7195 | transcript file. Only one transcript may be in progress at any time, | |
7196 | though some implementations may relax this restriction. The values | |
7197 | returned by these procedures are unspecified. | |
7198 | ||
7199 | @c \begin{note} | |
7200 | @c These procedures are redundant in some systems, but | |
7201 | @c systems that need them should provide them. | |
7202 | @c \end{note} | |
7203 | @end deffn | |
7204 | ||
7205 | @page | |
7206 | ||
7207 | @c @include{syn} | |
7208 | @node Formal syntax and semantics, Notes, Standard procedures, top | |
7209 | @chapter Formal syntax and semantics | |
7210 | ||
7211 | @menu | |
7212 | * Formal syntax:: | |
7213 | * Formal semantics:: | |
7214 | * Derived expression type:: | |
7215 | @end menu | |
7216 | ||
7217 | ||
7218 | ||
7219 | This chapter provides formal descriptions of what has already been | |
7220 | described informally in previous chapters of this report. | |
7221 | ||
7222 | @ignore todo | |
7223 | Allow grammar to say that else clause needn't be last? | |
7224 | @end ignore | |
7225 | ||
7226 | ||
7227 | ||
7228 | @node Formal syntax, Formal semantics, Formal syntax and semantics, Formal syntax and semantics | |
7229 | @section Formal syntax | |
7230 | ||
7231 | @menu | |
7232 | * Lexical structure:: | |
7233 | * External representation:: | |
7234 | * Expression:: | |
7235 | * Quasiquotations:: | |
7236 | * Transformers:: | |
7237 | * Programs and definitions:: | |
7238 | @end menu | |
7239 | ||
7240 | ||
7241 | ||
7242 | This section provides a formal syntax for Scheme written in an extended | |
7243 | BNF. | |
7244 | ||
7245 | All spaces in the grammar are for legibility. Case is insignificant; | |
7246 | for example, @samp{#x1A} and @samp{#X1a} are equivalent. <empty> | |
7247 | stands for the empty string. | |
7248 | ||
7249 | The following extensions to BNF are used to make the description more | |
7250 | concise: <thing>* means zero or more occurrences of | |
7251 | <thing>; and <thing>+ means at least one | |
7252 | <thing>. | |
7253 | ||
7254 | ||
7255 | @node Lexical structure, External representation, Formal syntax, Formal syntax | |
7256 | @subsection Lexical structure | |
7257 | ||
7258 | ||
7259 | This section describes how individual tokens (identifiers, | |
7260 | @cindex @w{token} | |
7261 | numbers, etc.) are formed from sequences of characters. The following | |
7262 | sections describe how expressions and programs are formed from sequences | |
7263 | of tokens. | |
7264 | ||
7265 | <Intertoken space> may occur on either side of any token, but not | |
7266 | within a token. | |
7267 | ||
7268 | Tokens which require implicit termination (identifiers, numbers, | |
7269 | characters, and dot) may be terminated by any <delimiter>, but not | |
7270 | necessarily by anything else. | |
7271 | ||
7272 | The following five characters are reserved for future extensions to the | |
7273 | language: @t{[ ] @{ @} |} | |
7274 | ||
7275 | ||
7276 | @format | |
7277 | @t{<token> --> <identifier> | <boolean> | <number> | |
7278 | @cindex @w{identifier} | |
7279 | | <character> | <string> | |
7280 | | ( | ) | #( | @t{'} | @t{`} | , | ,@@ | @b{.} | |
7281 | <delimiter> --> <whitespace> | ( | ) | " | ; | |
7282 | <whitespace> --> <space or newline> | |
7283 | <comment> --> ; <@r{all subsequent characters up to a} | |
7284 | @r{line break>} | |
7285 | @cindex @w{comment} | |
7286 | <atmosphere> --> <whitespace> | <comment> | |
7287 | <intertoken space> --> <atmosphere>*} | |
7288 | ||
7289 | @end format | |
7290 | ||
7291 | ||
7292 | ||
7293 | ||
7294 | ||
7295 | ||
7296 | @c This is a kludge, but \multicolumn doesn't work in tabbing environments. | |
7297 | ||
7298 | ||
7299 | ||
7300 | @format | |
7301 | @t{<identifier> --> <initial> <subsequent>* | |
7302 | | <peculiar identifier> | |
7303 | <initial> --> <letter> | <special initial> | |
7304 | <letter> --> a | b | c | ... | z | |
7305 | ||
7306 | <special initial> --> ! | $ | % | & | * | / | : | < | = | |
7307 | | > | ? | ^ | _ | ~ | |
7308 | <subsequent> --> <initial> | <digit> | |
7309 | | <special subsequent> | |
7310 | <digit> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | |
7311 | <special subsequent> --> + | - | .@: | @@ | |
7312 | <peculiar identifier> --> + | - | ... | |
7313 | <syntactic keyword> --> <expression keyword> | |
7314 | @cindex @w{syntactic keyword} | |
7315 | @cindex @w{keyword} | |
7316 | | else | => | define | |
7317 | | unquote | unquote-splicing | |
7318 | <expression keyword> --> quote | lambda | if | |
7319 | | set! | begin | cond | and | or | case | |
7320 | | let | let* | letrec | do | delay | |
7321 | | quasiquote | |
7322 | ||
7323 | @w{@samp{<variable> @result{} <}}@r{any <identifier> that isn't} | |
7324 | @cindex @w{variable} | |
7325 | @w{ @r{also a <syntactic keyword>>}} | |
7326 | ||
7327 | <boolean> --> #t | #f | |
7328 | <character> --> #\ <any character> | |
7329 | | #\ <character name> | |
7330 | <character name> --> space | newline | |
7331 | ||
7332 | <string> --> " <string element>* " | |
7333 | <string element> --> <any character other than " or \> | |
7334 | | \" | \\ } | |
7335 | ||
7336 | @end format | |
7337 | ||
7338 | ||
7339 | ||
7340 | ||
7341 | ||
7342 | ||
7343 | ||
7344 | @format | |
7345 | @t{<number> --> <num 2>| <num 8> | |
7346 | | <num 10>| <num 16> | |
7347 | } | |
7348 | ||
7349 | @end format | |
7350 | ||
7351 | ||
7352 | ||
7353 | The following rules for <num R>, <complex R>, <real | |
7354 | R>, <ureal R>, <uinteger R>, and <prefix R> | |
7355 | should be replicated for @w{R = 2, 8, 10,} | |
7356 | and 16. There are no rules for <decimal 2>, <decimal | |
7357 | 8>, and <decimal 16>, which means that numbers containing | |
7358 | decimal points or exponents must be in decimal radix. | |
7359 | @ignore todo | |
7360 | Mark Meyer and David Bartley want to fix this. (What? -- Will) | |
7361 | @end ignore | |
7362 | ||
7363 | ||
7364 | ||
7365 | @format | |
7366 | @t{<num R> --> <prefix R> <complex R> | |
7367 | <complex R> --> <real R> | <real R> @@ <real R> | |
7368 | | <real R> + <ureal R> i | <real R> - <ureal R> i | |
7369 | | <real R> + i | <real R> - i | |
7370 | | + <ureal R> i | - <ureal R> i | + i | - i | |
7371 | <real R> --> <sign> <ureal R> | |
7372 | <ureal R> --> <uinteger R> | |
7373 | | <uinteger R> / <uinteger R> | |
7374 | | <decimal R> | |
7375 | <decimal 10> --> <uinteger 10> <suffix> | |
7376 | | . <digit 10>+ #* <suffix> | |
7377 | | <digit 10>+ . <digit 10>* #* <suffix> | |
7378 | | <digit 10>+ #+ . #* <suffix> | |
7379 | <uinteger R> --> <digit R>+ #* | |
7380 | <prefix R> --> <radix R> <exactness> | |
7381 | | <exactness> <radix R> | |
7382 | } | |
7383 | ||
7384 | @end format | |
7385 | ||
7386 | ||
7387 | ||
7388 | ||
7389 | @format | |
7390 | @t{<suffix> --> <empty> | |
7391 | | <exponent marker> <sign> <digit 10>+ | |
7392 | <exponent marker> --> e | s | f | d | l | |
7393 | <sign> --> <empty> | + | - | |
7394 | <exactness> --> <empty> | #i | #e | |
7395 | @vindex #e | |
7396 | @vindex #i | |
7397 | <radix 2> --> #b | |
7398 | @vindex #b | |
7399 | <radix 8> --> #o | |
7400 | @vindex #o | |
7401 | <radix 10> --> <empty> | #d | |
7402 | <radix 16> --> #x | |
7403 | @vindex #x | |
7404 | <digit 2> --> 0 | 1 | |
7405 | <digit 8> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |
7406 | <digit 10> --> <digit> | |
7407 | <digit 16> --> <digit 10> | a | b | c | d | e | f } | |
7408 | ||
7409 | @end format | |
7410 | ||
7411 | ||
7412 | ||
7413 | @ignore todo | |
7414 | Mark Meyer of TI sez, shouldn't we allow @t{1e3/2}? | |
7415 | @end ignore | |
7416 | ||
7417 | ||
7418 | ||
7419 | @node External representation, Expression, Lexical structure, Formal syntax | |
7420 | @subsection External representations | |
7421 | ||
7422 | ||
7423 | ||
7424 | <Datum> is what the @code{read} procedure (section @pxref{Input}) | |
7425 | @vindex @w{read} | |
7426 | successfully parses. Note that any string that parses as an | |
7427 | <ex@-pres@-sion> will also parse as a <datum>. | |
7428 | ||
7429 | ||
7430 | @format | |
7431 | @t{<datum> --> <simple datum> | <compound datum> | |
7432 | <simple datum> --> <boolean> | <number> | |
7433 | | <character> | <string> | <symbol> | |
7434 | <symbol> --> <identifier> | |
7435 | <compound datum> --> <list> | <vector> | |
7436 | <list> --> (<datum>*) | (<datum>+ .@: <datum>) | |
7437 | | <abbreviation> | |
7438 | <abbreviation> --> <abbrev prefix> <datum> | |
7439 | <abbrev prefix> --> ' | ` | , | ,@@ | |
7440 | <vector> --> #(<datum>*) } | |
7441 | ||
7442 | @end format | |
7443 | ||
7444 | ||
7445 | ||
7446 | ||
7447 | @node Expression, Quasiquotations, External representation, Formal syntax | |
7448 | @subsection Expressions | |
7449 | ||
7450 | ||
7451 | ||
7452 | @format | |
7453 | @t{<expression> --> <variable> | |
7454 | | <literal> | |
7455 | | <procedure call> | |
7456 | | <lambda expression> | |
7457 | | <conditional> | |
7458 | | <assignment> | |
7459 | | <derived expression> | |
7460 | | <macro use> | |
7461 | | <macro block> | |
7462 | ||
7463 | <literal> --> <quotation> | <self-evaluating> | |
7464 | <self-evaluating> --> <boolean> | <number> | |
7465 | | <character> | <string> | |
7466 | <quotation> --> '<datum> | (quote <datum>) | |
7467 | <procedure call> --> (<operator> <operand>*) | |
7468 | <operator> --> <expression> | |
7469 | <operand> --> <expression> | |
7470 | ||
7471 | <lambda expression> --> (lambda <formals> <body>) | |
7472 | <formals> --> (<variable>*) | <variable> | |
7473 | | (<variable>+ .@: <variable>) | |
7474 | <body> --> <definition>* <sequence> | |
7475 | <sequence> --> <command>* <expression> | |
7476 | <command> --> <expression> | |
7477 | ||
7478 | <conditional> --> (if <test> <consequent> <alternate>) | |
7479 | <test> --> <expression> | |
7480 | <consequent> --> <expression> | |
7481 | <alternate> --> <expression> | <empty> | |
7482 | ||
7483 | <assignment> --> (set! <variable> <expression>) | |
7484 | ||
7485 | <derived expression> --> | |
7486 | (cond <cond clause>+) | |
7487 | | (cond <cond clause>* (else <sequence>)) | |
7488 | | (case <expression> | |
7489 | <case clause>+) | |
7490 | | (case <expression> | |
7491 | <case clause>* | |
7492 | (else <sequence>)) | |
7493 | | (and <test>*) | |
7494 | | (or <test>*) | |
7495 | | (let (<binding spec>*) <body>) | |
7496 | | (let <variable> (<binding spec>*) <body>) | |
7497 | | (let* (<binding spec>*) <body>) | |
7498 | | (letrec (<binding spec>*) <body>) | |
7499 | | (begin <sequence>) | |
7500 | | (do (<iteration spec>*) | |
7501 | (<test> <do result>) | |
7502 | <command>*) | |
7503 | | (delay <expression>) | |
7504 | | <quasiquotation> | |
7505 | ||
7506 | <cond clause> --> (<test> <sequence>) | |
7507 | | (<test>) | |
7508 | | (<test> => <recipient>) | |
7509 | <recipient> --> <expression> | |
7510 | <case clause> --> ((<datum>*) <sequence>) | |
7511 | <binding spec> --> (<variable> <expression>) | |
7512 | <iteration spec> --> (<variable> <init> <step>) | |
7513 | | (<variable> <init>) | |
7514 | <init> --> <expression> | |
7515 | <step> --> <expression> | |
7516 | <do result> --> <sequence> | <empty> | |
7517 | ||
7518 | <macro use> --> (<keyword> <datum>*) | |
7519 | <keyword> --> <identifier> | |
7520 | ||
7521 | <macro block> --> | |
7522 | (let-syntax (<syntax spec>*) <body>) | |
7523 | | (letrec-syntax (<syntax spec>*) <body>) | |
7524 | <syntax spec> --> (<keyword> <transformer spec>) | |
7525 | ||
7526 | } | |
7527 | ||
7528 | @end format | |
7529 | ||
7530 | ||
7531 | ||
7532 | @node Quasiquotations, Transformers, Expression, Formal syntax | |
7533 | @subsection Quasiquotations | |
7534 | ||
7535 | ||
7536 | The following grammar for quasiquote expressions is not context-free. | |
7537 | It is presented as a recipe for generating an infinite number of | |
7538 | production rules. Imagine a copy of the following rules for D = 1, 2,3, @dots{}. D keeps track of the nesting depth. | |
7539 | ||
7540 | ||
7541 | @format | |
7542 | @t{<quasiquotation> --> <quasiquotation 1> | |
7543 | <qq template 0> --> <expression> | |
7544 | <quasiquotation D> --> `<qq template D> | |
7545 | | (quasiquote <qq template D>) | |
7546 | <qq template D> --> <simple datum> | |
7547 | | <list qq template D> | |
7548 | | <vector qq template D> | |
7549 | | <unquotation D> | |
7550 | <list qq template D> --> (<qq template or splice D>*) | |
7551 | | (<qq template or splice D>+ .@: <qq template D>) | |
7552 | | '<qq template D> | |
7553 | | <quasiquotation D+1> | |
7554 | <vector qq template D> --> #(<qq template or splice D>*) | |
7555 | <unquotation D> --> ,<qq template D-1> | |
7556 | | (unquote <qq template D-1>) | |
7557 | <qq template or splice D> --> <qq template D> | |
7558 | | <splicing unquotation D> | |
7559 | <splicing unquotation D> --> ,@@<qq template D-1> | |
7560 | | (unquote-splicing <qq template D-1>) } | |
7561 | ||
7562 | @end format | |
7563 | ||
7564 | ||
7565 | ||
7566 | In <quasiquotation>s, a <list qq template D> can sometimes | |
7567 | be confused with either an <un@-quota@-tion D> or a <splicing | |
7568 | un@-quo@-ta@-tion D>. The interpretation as an | |
7569 | <un@-quo@-ta@-tion> or <splicing | |
7570 | un@-quo@-ta@-tion D> takes precedence. | |
7571 | ||
7572 | @node Transformers, Programs and definitions, Quasiquotations, Formal syntax | |
7573 | @subsection Transformers | |
7574 | ||
7575 | ||
7576 | ||
7577 | @format | |
7578 | @t{<transformer spec> --> | |
7579 | (syntax-rules (<identifier>*) <syntax rule>*) | |
7580 | <syntax rule> --> (<pattern> <template>) | |
7581 | <pattern> --> <pattern identifier> | |
7582 | | (<pattern>*) | |
7583 | | (<pattern>+ . <pattern>) | |
7584 | | (<pattern>* <pattern> <ellipsis>) | |
7585 | | #(<pattern>*) | |
7586 | | #(<pattern>* <pattern> <ellipsis>) | |
7587 | | <pattern datum> | |
7588 | <pattern datum> --> <string> | |
7589 | | <character> | |
7590 | | <boolean> | |
7591 | | <number> | |
7592 | <template> --> <pattern identifier> | |
7593 | | (<template element>*) | |
7594 | | (<template element>+ . <template>) | |
7595 | | #(<template element>*) | |
7596 | | <template datum> | |
7597 | <template element> --> <template> | |
7598 | | <template> <ellipsis> | |
7599 | <template datum> --> <pattern datum> | |
7600 | <pattern identifier> --> <any identifier except @samp{...}> | |
7601 | <ellipsis> --> <the identifier @samp{...}> | |
7602 | } | |
7603 | ||
7604 | @end format | |
7605 | ||
7606 | ||
7607 | ||
7608 | @node Programs and definitions, , Transformers, Formal syntax | |
7609 | @subsection Programs and definitions | |
7610 | ||
7611 | ||
7612 | ||
7613 | @format | |
7614 | @t{<program> --> <command or definition>* | |
7615 | <command or definition> --> <command> | |
7616 | | <definition> | |
7617 | | <syntax definition> | |
7618 | | (begin <command or definition>+) | |
7619 | <definition> --> (define <variable> <expression>) | |
7620 | | (define (<variable> <def formals>) <body>) | |
7621 | | (begin <definition>*) | |
7622 | <def formals> --> <variable>* | |
7623 | | <variable>* .@: <variable> | |
7624 | <syntax definition> --> | |
7625 | (define-syntax <keyword> <transformer spec>) | |
7626 | } | |
7627 | ||
7628 | @end format | |
7629 | ||
7630 | ||
7631 | ||
7632 | @node Formal semantics, Derived expression type, Formal syntax, Formal syntax and semantics | |
7633 | @section Formal semantics | |
7634 | ||
7635 | ||
7636 | This section provides a formal denotational semantics for the primitive | |
7637 | expressions of Scheme and selected built-in procedures. The concepts | |
7638 | and notation used here are described in @sc{[Stoy77]}. | |
7639 | ||
7640 | @quotation | |
7641 | @emph{Note:} The formal semantics section was written in La@TeX{} which | |
7642 | is incompatible with @TeX{}info. See the Formal semantics section of | |
7643 | the original document from which this was derived. | |
7644 | @end quotation | |
7645 | ||
7646 | ||
7647 | @c @include{derive} | |
7648 | @node Derived expression type, , Formal semantics, Formal syntax and semantics | |
7649 | @section Derived expression types | |
7650 | ||
7651 | ||
7652 | ||
7653 | This section gives macro definitions for the derived expression types in | |
7654 | terms of the primitive expression types (literal, variable, call, @samp{lambda}, | |
7655 | @samp{if}, @samp{set!}). See section @ref{Control features} for a possible | |
7656 | definition of @samp{delay}. | |
7657 | ||
7658 | ||
7659 | @example | |
7660 | ||
7661 | (define-syntax cond | |
7662 | (syntax-rules (else =>) | |
7663 | ((cond (else result1 result2 ...)) | |
7664 | (begin result1 result2 ...)) | |
7665 | ((cond (test => result)) | |
7666 | (let ((temp test)) | |
7667 | (if temp (result temp)))) | |
7668 | ((cond (test => result) clause1 clause2 ...) | |
7669 | (let ((temp test)) | |
7670 | (if temp | |
7671 | (result temp) | |
7672 | (cond clause1 clause2 ...)))) | |
7673 | ((cond (test)) test) | |
7674 | ((cond (test) clause1 clause2 ...) | |
7675 | (let ((temp test)) | |
7676 | (if temp | |
7677 | temp | |
7678 | (cond clause1 clause2 ...)))) | |
7679 | ((cond (test result1 result2 ...)) | |
7680 | (if test (begin result1 result2 ...))) | |
7681 | ((cond (test result1 result2 ...) | |
7682 | clause1 clause2 ...) | |
7683 | (if test | |
7684 | (begin result1 result2 ...) | |
7685 | (cond clause1 clause2 ...))))) | |
7686 | ||
7687 | @end example | |
7688 | ||
7689 | ||
7690 | ||
7691 | @example | |
7692 | ||
7693 | (define-syntax case | |
7694 | (syntax-rules (else) | |
7695 | ((case (key ...) | |
7696 | clauses ...) | |
7697 | (let ((atom-key (key ...))) | |
7698 | (case atom-key clauses ...))) | |
7699 | ((case key | |
7700 | (else result1 result2 ...)) | |
7701 | (begin result1 result2 ...)) | |
7702 | ((case key | |
7703 | ((atoms ...) result1 result2 ...)) | |
7704 | (if (memv key '(atoms ...)) | |
7705 | (begin result1 result2 ...))) | |
7706 | ((case key | |
7707 | ((atoms ...) result1 result2 ...) | |
7708 | clause clauses ...) | |
7709 | (if (memv key '(atoms ...)) | |
7710 | (begin result1 result2 ...) | |
7711 | (case key clause clauses ...))))) | |
7712 | ||
7713 | @end example | |
7714 | ||
7715 | ||
7716 | ||
7717 | @example | |
7718 | ||
7719 | (define-syntax and | |
7720 | (syntax-rules () | |
7721 | ((and) #t) | |
7722 | ((and test) test) | |
7723 | ((and test1 test2 ...) | |
7724 | (if test1 (and test2 ...) #f)))) | |
7725 | ||
7726 | @end example | |
7727 | ||
7728 | ||
7729 | ||
7730 | @example | |
7731 | ||
7732 | (define-syntax or | |
7733 | (syntax-rules () | |
7734 | ((or) #f) | |
7735 | ((or test) test) | |
7736 | ((or test1 test2 ...) | |
7737 | (let ((x test1)) | |
7738 | (if x x (or test2 ...)))))) | |
7739 | ||
7740 | @end example | |
7741 | ||
7742 | ||
7743 | ||
7744 | @example | |
7745 | ||
7746 | (define-syntax let | |
7747 | (syntax-rules () | |
7748 | ((let ((name val) ...) body1 body2 ...) | |
7749 | ((lambda (name ...) body1 body2 ...) | |
7750 | val ...)) | |
7751 | ((let tag ((name val) ...) body1 body2 ...) | |
7752 | ((letrec ((tag (lambda (name ...) | |
7753 | body1 body2 ...))) | |
7754 | tag) | |
7755 | val ...)))) | |
7756 | ||
7757 | @end example | |
7758 | ||
7759 | ||
7760 | ||
7761 | @example | |
7762 | ||
7763 | (define-syntax let* | |
7764 | (syntax-rules () | |
7765 | ((let* () body1 body2 ...) | |
7766 | (let () body1 body2 ...)) | |
7767 | ((let* ((name1 val1) (name2 val2) ...) | |
7768 | body1 body2 ...) | |
7769 | (let ((name1 val1)) | |
7770 | (let* ((name2 val2) ...) | |
7771 | body1 body2 ...))))) | |
7772 | ||
7773 | @end example | |
7774 | ||
7775 | ||
7776 | The following @samp{letrec} macro uses the symbol @samp{<undefined>} | |
7777 | in place of an expression which returns something that when stored in | |
7778 | a location makes it an error to try to obtain the value stored in the | |
7779 | location (no such expression is defined in Scheme). | |
7780 | A trick is used to generate the temporary names needed to avoid | |
7781 | specifying the order in which the values are evaluated. | |
7782 | This could also be accomplished by using an auxiliary macro. | |
7783 | ||
7784 | ||
7785 | @example | |
7786 | ||
7787 | (define-syntax letrec | |
7788 | (syntax-rules () | |
7789 | ((letrec ((var1 init1) ...) body ...) | |
7790 | (letrec "generate temp names" | |
7791 | (var1 ...) | |
7792 | () | |
7793 | ((var1 init1) ...) | |
7794 | body ...)) | |
7795 | ((letrec "generate temp names" | |
7796 | () | |
7797 | (temp1 ...) | |
7798 | ((var1 init1) ...) | |
7799 | body ...) | |
7800 | (let ((var1 <undefined>) ...) | |
7801 | (let ((temp1 init1) ...) | |
7802 | (set! var1 temp1) | |
7803 | ... | |
7804 | body ...))) | |
7805 | ((letrec "generate temp names" | |
7806 | (x y ...) | |
7807 | (temp ...) | |
7808 | ((var1 init1) ...) | |
7809 | body ...) | |
7810 | (letrec "generate temp names" | |
7811 | (y ...) | |
7812 | (newtemp temp ...) | |
7813 | ((var1 init1) ...) | |
7814 | body ...)))) | |
7815 | ||
7816 | @end example | |
7817 | ||
7818 | ||
7819 | ||
7820 | @example | |
7821 | ||
7822 | (define-syntax begin | |
7823 | (syntax-rules () | |
7824 | ((begin exp ...) | |
7825 | ((lambda () exp ...))))) | |
7826 | ||
7827 | @end example | |
7828 | ||
7829 | ||
7830 | The following alternative expansion for @samp{begin} does not make use of | |
7831 | the ability to write more than one expression in the body of a lambda | |
7832 | expression. In any case, note that these rules apply only if the body | |
7833 | of the @samp{begin} contains no definitions. | |
7834 | ||
7835 | ||
7836 | @example | |
7837 | ||
7838 | (define-syntax begin | |
7839 | (syntax-rules () | |
7840 | ((begin exp) | |
7841 | exp) | |
7842 | ((begin exp1 exp2 ...) | |
7843 | (let ((x exp1)) | |
7844 | (begin exp2 ...))))) | |
7845 | ||
7846 | @end example | |
7847 | ||
7848 | ||
7849 | The following definition | |
7850 | of @samp{do} uses a trick to expand the variable clauses. | |
7851 | As with @samp{letrec} above, an auxiliary macro would also work. | |
7852 | The expression @samp{(if #f #f)} is used to obtain an unspecific | |
7853 | value. | |
7854 | ||
7855 | ||
7856 | @example | |
7857 | ||
7858 | (define-syntax do | |
7859 | (syntax-rules () | |
7860 | ((do ((var init step ...) ...) | |
7861 | (test expr ...) | |
7862 | command ...) | |
7863 | (letrec | |
7864 | ((loop | |
7865 | (lambda (var ...) | |
7866 | (if test | |
7867 | (begin | |
7868 | (if #f #f) | |
7869 | expr ...) | |
7870 | (begin | |
7871 | command | |
7872 | ... | |
7873 | (loop (do "step" var step ...) | |
7874 | ...)))))) | |
7875 | (loop init ...))) | |
7876 | ((do "step" x) | |
7877 | x) | |
7878 | ((do "step" x y) | |
7879 | y))) | |
7880 | ||
7881 | @end example | |
7882 | ||
7883 | ||
7884 | @c `a = Q_1[a] | |
7885 | @c `(a b c ... . z) = `(a . (b c ...)) | |
7886 | @c `(a . b) = (append Q*_0[a] `b) | |
7887 | @c `(a) = Q*_0[a] | |
7888 | @c Q*_0[a] = (list 'a) | |
7889 | @c Q*_0[,a] = (list a) | |
7890 | @c Q*_0[,@a] = a | |
7891 | @c Q*_0[`a] = (list 'quasiquote Q*_1[a]) | |
7892 | @c `#(a b ...) = (list->vector `(a b ...)) | |
7893 | @c ugh. | |
7894 | ||
7895 | @page | |
7896 | ||
7897 | @c @include{notes} | |
7898 | @node Notes, Additional material, Formal syntax and semantics, top | |
7899 | @unnumbered Notes | |
7900 | ||
7901 | @menu | |
7902 | * Language changes:: | |
7903 | @end menu | |
7904 | ||
7905 | ||
7906 | ||
7907 | @ignore todo | |
7908 | Perhaps this section should be made to disappear. | |
7909 | Can these remarks be moved somewhere else? | |
7910 | @end ignore | |
7911 | ||
7912 | ||
7913 | @node Language changes, , Notes, Notes | |
7914 | @unnumberedsec Language changes | |
7915 | ||
7916 | ||
7917 | ||
7918 | This section enumerates the changes that have been made to Scheme since | |
7919 | the ``Revised^4 report'' [R4RS] was published. | |
7920 | ||
7921 | ||
7922 | ||
7923 | @itemize @bullet | |
7924 | ||
7925 | ||
7926 | @item | |
7927 | The report is now a superset of the IEEE standard for Scheme | |
7928 | [IEEEScheme]: implementations that conform to the report will | |
7929 | also conform to the standard. This required the following changes: | |
7930 | ||
7931 | ||
7932 | @itemize @bullet | |
7933 | ||
7934 | ||
7935 | @item | |
7936 | The empty list is now required to count as true. | |
7937 | ||
7938 | @item | |
7939 | The classification of features as essential or inessential has been | |
7940 | removed. There are now three classes of built-in procedures: primitive, | |
7941 | library, and optional. The optional procedures are @samp{load}, | |
7942 | @samp{with-input-from-file}, @samp{with-output-to-file}, | |
7943 | @samp{transcript-on}, @samp{transcript-off}, and | |
7944 | @samp{interaction-environment}, | |
7945 | and @samp{-} and @samp{/} with more than two arguments. | |
7946 | None of these are in the IEEE standard. | |
7947 | ||
7948 | @item | |
7949 | Programs are allowed to redefine built-in procedures. Doing so | |
7950 | will not change the behavior of other built-in procedures. | |
7951 | ||
7952 | @end itemize | |
7953 | ||
7954 | ||
7955 | @item | |
7956 | @emph{Port} has been added to the list of disjoint types. | |
7957 | ||
7958 | @item | |
7959 | The macro appendix has been removed. High-level macros are now part | |
7960 | of the main body of the report. The rewrite rules for derived expressions | |
7961 | have been replaced with macro definitions. There are no reserved identifiers. | |
7962 | ||
7963 | @item | |
7964 | @samp{Syntax-rules} now allows vector patterns. | |
7965 | ||
7966 | @item | |
7967 | Multiple-value returns, @samp{eval}, and @samp{dynamic-wind} have | |
7968 | been added. | |
7969 | ||
7970 | @item | |
7971 | The calls that are required to be implemented in a properly tail-recursive | |
7972 | fashion are defined explicitly. | |
7973 | ||
7974 | @item | |
7975 | `@samp{@@}' can be used within identifiers. `@samp{|}' is reserved | |
7976 | for possible future extensions. | |
7977 | ||
7978 | ||
7979 | @end itemize | |
7980 | ||
7981 | ||
7982 | @c %R4%% | |
7983 | @c \subsection*{Keywords as variable names} | |
7984 | ||
7985 | @c Some implementations allow arbitrary syntactic | |
7986 | @c keywords \index{keyword}\index{syntactic keyword}to be used as variable | |
7987 | @c names, instead of reserving them, as this report would have | |
7988 | @c it.\index{variable} But this creates ambiguities in the interpretation | |
7989 | @c of expressions: for example, in the following, it's not clear whether | |
7990 | @c the expression {\tt (if 1 2 3)} should be treated as a procedure call or | |
7991 | @c as a conditional. | |
7992 | ||
7993 | @c \begin{scheme} | |
7994 | @c (define if list) | |
7995 | @c (if 1 2 3) \ev 2 {\em{}or} (1 2 3)% | |
7996 | @c \end{scheme} | |
7997 | ||
7998 | @c These ambiguities are usually resolved in some consistent way within any | |
7999 | @c given implementation, but no particular treatment stands out as being | |
8000 | @c clearly superior to any other, so these situations were excluded for the | |
8001 | @c purposes of this report. | |
8002 | ||
8003 | @c %R4%% | |
8004 | @c \subsection*{Macros} | |
8005 | ||
8006 | @c Scheme does not have any standard facility for defining new kinds of | |
8007 | @c expressions.\index{macros} | |
8008 | ||
8009 | @c \vest The ability to alter the syntax of the language creates | |
8010 | @c numerous problems. All current implementations of Scheme have macro | |
8011 | @c facilities that solve those problems to one degree or another, but the | |
8012 | @c solutions are quite different and it isn't clear at this time which | |
8013 | @c solution is best, or indeed whether any of the solutions are truly | |
8014 | @c adequate. Rather than standardize, we are encouraging implementations | |
8015 | @c to continue to experiment with different solutions. | |
8016 | ||
8017 | @c \vest The main problems with traditional macros are: They must be | |
8018 | @c defined to the system before any code using them is loaded; this is a | |
8019 | @c common source of obscure bugs. They are usually global; macros can be | |
8020 | @c made to follow lexical scope rules \todo{flushed: ``as in Common | |
8021 | @c Lisp's {\tt macrolet}''; OK?}, but many people find the resulting scope rules | |
8022 | @c confusing. Unless they are written very carefully, macros are | |
8023 | @c vulnerable to inadvertent capture of free variables; to get around this, | |
8024 | @c for example, macros may have to generate code in which procedure values | |
8025 | @c appear as quoted constants. There is a similar problem with syntactic | |
8026 | @c keywords if the keywords of special forms are not reserved. If keywords | |
8027 | @c are reserved, then either macros introduce new reserved words, | |
8028 | @c invalidating old code, or else special forms defined by the programmer | |
8029 | @c do not have the same status as special forms defined by the system. | |
8030 | ||
8031 | @c \todo{Refer to Pitman's special forms paper.} | |
8032 | @c \todo{Pitman sez: Discuss importance of having a small number of special forms | |
8033 | @c so that programs can inspect each other.} | |
8034 | ||
8035 | @ignore todo | |
8036 | Move cwcc history back here? --- Andy Cromarty is concerned about | |
8037 | confusion over who the audience is. | |
8038 | @end ignore | |
8039 | ||
8040 | ||
8041 | @ignore todo | |
8042 | Cromarty: | |
8043 | 23. NOTES, p.35ff.: This material should stay somehow. We need to | |
8044 | make it clear that R^3 Scheme is not being touted as Yet Another | |
8045 | Ultimate Solution To The Programming Language Problem, but rather | |
8046 | as a snapshot of a *process* of good design, for which not all | |
8047 | answers have yet been found. We also ought to use the opportunity | |
8048 | for publicity afforded us by SIGPLAN to advertise some of the thorny | |
8049 | unsolved problems that need further research, and encourage | |
8050 | language designers to work on them. | |
8051 | @end ignore | |
8052 | ||
8053 | ||
8054 | @c @include{repository} | |
8055 | @node Additional material, Example, Notes, top | |
8056 | @unnumbered Additional material | |
8057 | ||
8058 | ||
8059 | The Internet Scheme Repository at | |
8060 | ||
8061 | @center | |
8062 | @center @url{http://www.cs.indiana.edu/scheme-repository/} | |
8063 | @center | |
8064 | ||
8065 | contains an extensive Scheme bibliography, as well as papers, | |
8066 | programs, implementations, and other material related to Scheme. | |
8067 | ||
8068 | @page | |
8069 | ||
8070 | @c @include{example} | |
8071 | ||
8072 | @node Example, Bibliography, Additional material, top | |
8073 | @unnumbered Example | |
8074 | ||
8075 | @c -*- Mode: Lisp; Package: SCHEME; Syntax: Common-lisp -*- | |
8076 | ||
8077 | ||
8078 | @samp{Integrate-system} integrates the system | |
8079 | ||
8080 | ||
8081 | @center y_k^^ = f_k(y_1, y_2, @dots{}, y_n), k = 1, @dots{}, n | |
8082 | ||
8083 | of differential equations with the method of Runge-Kutta. | |
8084 | ||
8085 | The parameter @t{system-derivative} is a function that takes a system | |
8086 | state (a vector of values for the state variables y_1, @dots{}, y_n) | |
8087 | and produces a system derivative (the values y_1^^, @dots{},y_n^^). The parameter @t{initial-state} provides an initial | |
8088 | system state, and @t{h} is an initial guess for the length of the | |
8089 | integration step. | |
8090 | ||
8091 | The value returned by @samp{integrate-system} is an infinite stream of | |
8092 | system states. | |
8093 | ||
8094 | ||
8095 | @example | |
8096 | ||
8097 | (define integrate-system | |
8098 | (lambda (system-derivative initial-state h) | |
8099 | (let ((next (runge-kutta-4 system-derivative h))) | |
8100 | (letrec ((states | |
8101 | (cons initial-state | |
8102 | (delay (map-streams next | |
8103 | states))))) | |
8104 | states)))) | |
8105 | ||
8106 | @end example | |
8107 | ||
8108 | ||
8109 | @samp{Runge-Kutta-4} takes a function, @t{f}, that produces a | |
8110 | system derivative from a system state. @samp{Runge-Kutta-4} | |
8111 | produces a function that takes a system state and | |
8112 | produces a new system state. | |
8113 | ||
8114 | ||
8115 | @example | |
8116 | ||
8117 | (define runge-kutta-4 | |
8118 | (lambda (f h) | |
8119 | (let ((*h (scale-vector h)) | |
8120 | (*2 (scale-vector 2)) | |
8121 | (*1/2 (scale-vector (/ 1 2))) | |
8122 | (*1/6 (scale-vector (/ 1 6)))) | |
8123 | (lambda (y) | |
8124 | ;; y @r{}is a system state | |
8125 | (let* ((k0 (*h (f y))) | |
8126 | (k1 (*h (f (add-vectors y (*1/2 k0))))) | |
8127 | (k2 (*h (f (add-vectors y (*1/2 k1))))) | |
8128 | (k3 (*h (f (add-vectors y k2))))) | |
8129 | (add-vectors y | |
8130 | (*1/6 (add-vectors k0 | |
8131 | (*2 k1) | |
8132 | (*2 k2) | |
8133 | k3)))))))) | |
8134 | @c |--------------------------------------------------| | |
8135 | ||
8136 | (define elementwise | |
8137 | (lambda (f) | |
8138 | (lambda vectors | |
8139 | (generate-vector | |
8140 | (vector-length (car vectors)) | |
8141 | (lambda (i) | |
8142 | (apply f | |
8143 | (map (lambda (v) (vector-ref v i)) | |
8144 | vectors))))))) | |
8145 | ||
8146 | @c |--------------------------------------------------| | |
8147 | (define generate-vector | |
8148 | (lambda (size proc) | |
8149 | (let ((ans (make-vector size))) | |
8150 | (letrec ((loop | |
8151 | (lambda (i) | |
8152 | (cond ((= i size) ans) | |
8153 | (else | |
8154 | (vector-set! ans i (proc i)) | |
8155 | (loop (+ i 1))))))) | |
8156 | (loop 0))))) | |
8157 | ||
8158 | (define add-vectors (elementwise +)) | |
8159 | ||
8160 | (define scale-vector | |
8161 | (lambda (s) | |
8162 | (elementwise (lambda (x) (* x s))))) | |
8163 | ||
8164 | @end example | |
8165 | ||
8166 | ||
8167 | @samp{Map-streams} is analogous to @samp{map}: it applies its first | |
8168 | argument (a procedure) to all the elements of its second argument (a | |
8169 | stream). | |
8170 | ||
8171 | ||
8172 | @example | |
8173 | ||
8174 | (define map-streams | |
8175 | (lambda (f s) | |
8176 | (cons (f (head s)) | |
8177 | (delay (map-streams f (tail s)))))) | |
8178 | ||
8179 | @end example | |
8180 | ||
8181 | ||
8182 | Infinite streams are implemented as pairs whose car holds the first | |
8183 | element of the stream and whose cdr holds a promise to deliver the rest | |
8184 | of the stream. | |
8185 | ||
8186 | ||
8187 | @example | |
8188 | ||
8189 | (define head car) | |
8190 | (define tail | |
8191 | (lambda (stream) (force (cdr stream)))) | |
8192 | ||
8193 | @end example | |
8194 | ||
8195 | ||
8196 | @sp 6 | |
8197 | The following illustrates the use of @samp{integrate-system} in | |
8198 | integrating the system | |
8199 | ||
8200 | ||
8201 | @center C dv_C / dt = -i_L - v_C / R | |
8202 | ||
8203 | ||
8204 | ||
8205 | @center L di_L / dt = v_C | |
8206 | ||
8207 | which models a damped oscillator. | |
8208 | ||
8209 | ||
8210 | @example | |
8211 | ||
8212 | (define damped-oscillator | |
8213 | (lambda (R L C) | |
8214 | (lambda (state) | |
8215 | (let ((Vc (vector-ref state 0)) | |
8216 | (Il (vector-ref state 1))) | |
8217 | (vector (- 0 (+ (/ Vc (* R C)) (/ Il C))) | |
8218 | (/ Vc L)))))) | |
8219 | ||
8220 | (define the-states | |
8221 | (integrate-system | |
8222 | (damped-oscillator 10000 1000 .001) | |
8223 | '#(1 0) | |
8224 | .01)) | |
8225 | ||
8226 | @end example | |
8227 | ||
8228 | ||
8229 | @ignore todo | |
8230 | Show some output? | |
8231 | @end ignore | |
8232 | ||
8233 | ||
8234 | @c (letrec ((loop (lambda (s) | |
8235 | @c (newline) | |
8236 | @c (write (head s)) | |
8237 | @c (loop (tail s))))) | |
8238 | @c (loop the-states)) | |
8239 | ||
8240 | @c #(1 0) | |
8241 | @c #(0.99895054 9.994835e-6) | |
8242 | @c #(0.99780226 1.9978681e-5) | |
8243 | @c #(0.9965554 2.9950552e-5) | |
8244 | @c #(0.9952102 3.990946e-5) | |
8245 | @c #(0.99376684 4.985443e-5) | |
8246 | @c #(0.99222565 5.9784474e-5) | |
8247 | @c #(0.9905868 6.969862e-5) | |
8248 | @c #(0.9888506 7.9595884e-5) | |
8249 | @c #(0.9870173 8.94753e-5) | |
8250 | ||
8251 | @page | |
8252 | ||
8253 | @c \newpage % Put bib on it's own page (it's just one) | |
8254 | @c \twocolumn[\vspace{-.18in}]% Last bib item was on a page by itself. | |
8255 | @c \renewcommand{\bibname}{References} | |
8256 | @c @include{bib} | |
8257 | ||
8258 | @c My reference for proper reference format is: | |
8259 | @c Mary-Claire van Leunen. | |
8260 | @c {\em A Handbook for Scholars.} | |
8261 | @c Knopf, 1978. | |
8262 | @c I think the references list would look better in ``open'' format, | |
8263 | @c i.e. with the three blocks for each entry appearing on separate | |
8264 | @c lines. I used the compressed format for SIGPLAN in the interest of | |
8265 | @c space. In open format, when a block runs over one line, | |
8266 | @c continuation lines should be indented; this could probably be done | |
8267 | @c using some flavor of latex list environment. Maybe the right thing | |
8268 | @c to do in the long run would be to convert to Bibtex, which probably | |
8269 | @c does the right thing, since it was implemented by one of van | |
8270 | @c Leunen's colleagues at DEC SRC. | |
8271 | @c -- Jonathan | |
8272 | ||
8273 | @c I tried to follow Jonathan's format, insofar as I understood it. | |
8274 | @c I tried to order entries lexicographically by authors (with singly | |
8275 | @c authored papers first), then by date. | |
8276 | @c In some cases I replaced a technical report or conference paper | |
8277 | @c by a subsequent journal article, but I think there are several | |
8278 | @c more such replacements that ought to be made. | |
8279 | @c -- Will, 1991. | |
8280 | ||
8281 | @c This is just a personal remark on your question on the RRRS: | |
8282 | @c The language CUCH (Curry-Church) was implemented by 1964 and | |
8283 | @c is a practical version of the lambda-calculus (call-by-name). | |
8284 | @c One reference you may find in Formal Language Description Languages | |
8285 | @c for Computer Programming T.~B.~Steele, 1965 (or so). | |
8286 | @c -- Matthias Felleisen | |
8287 | ||
8288 | @c Rather than try to keep the bibliography up-to-date, which is hopeless | |
8289 | @c given the time between updates, I replaced the bulk of the references | |
8290 | @c with a pointer to the Scheme Repository. Ozan Yigit's bibliography in | |
8291 | @c the repository is a superset of the R4RS one. | |
8292 | @c The bibliography now contains only items referenced within the report. | |
8293 | @c -- Richard, 1996. | |
8294 | ||
8295 | @node Bibliography, Index, Example, top | |
8296 | @unnumbered Bibliography | |
8297 | ||
8298 | ||
8299 | @itemize @bullet | |
8300 | @c 999 | |
8301 | ||
8302 | ||
8303 | @item [SICP] | |
8304 | @pindex SICP | |
8305 | Harold Abelson and Gerald Jay Sussman with Julie Sussman. | |
8306 | @emph{Structure and Interpretation of Computer Programs, second edition.} | |
8307 | MIT Press, Cambridge, 1996. | |
8308 | ||
8309 | @item [Bawden88] | |
8310 | @c new | |
8311 | Alan Bawden and Jonathan Rees. | |
8312 | @pindex Bawden88 | |
8313 | Syntactic closures. | |
8314 | In @emph{Proceedings of the 1988 ACM Symposium on Lisp and | |
8315 | Functional Programming}, pages 86--95. | |
8316 | ||
8317 | @item [howtoprint] | |
8318 | @pindex howtoprint | |
8319 | Robert G. Burger and R. Kent Dybvig. | |
8320 | Printing floating-point numbers quickly and accurately. | |
8321 | In @emph{Proceedings of the ACM SIGPLAN '96 Conference | |
8322 | on Programming Language Design and Implementation}, pages 108--116. | |
8323 | ||
8324 | @item [RRRS] | |
8325 | @pindex RRRS | |
8326 | William Clinger, editor. | |
8327 | The revised revised report on Scheme, or an uncommon Lisp. | |
8328 | MIT Artificial Intelligence Memo 848, August 1985. | |
8329 | Also published as Computer Science Department Technical Report 174, | |
8330 | Indiana University, June 1985. | |
8331 | ||
8332 | @item [howtoread] | |
8333 | @c new | |
8334 | William Clinger. | |
8335 | @pindex howtoread | |
8336 | How to read floating point numbers accurately. | |
8337 | In @emph{Proceedings of the ACM SIGPLAN '90 Conference | |
8338 | on Programming Language Design and Implementation}, pages 92--101. | |
8339 | Proceedings published as @emph{SIGPLAN Notices} 25(6), June 1990. | |
8340 | ||
8341 | @item [R4RS] | |
8342 | @pindex R4RS | |
8343 | William Clinger and Jonathan Rees, editors. | |
8344 | The revised^4 report on the algorithmic language Scheme. | |
8345 | In @emph{ACM Lisp Pointers} 4(3), pages 1--55, 1991. | |
8346 | ||
8347 | @item [macrosthatwork] | |
8348 | @c new | |
8349 | William Clinger and Jonathan Rees. | |
8350 | @pindex macrosthatwork | |
8351 | Macros that work. | |
8352 | In @emph{Proceedings of the 1991 ACM Conference on Principles of | |
8353 | Programming Languages}, pages 155--162. | |
8354 | ||
8355 | @item [propertailrecursion] | |
8356 | @c new | |
8357 | William Clinger. | |
8358 | @pindex propertailrecursion | |
8359 | Proper Tail Recursion and Space Efficiency. | |
8360 | To appear in @emph{Proceedings of the 1998 ACM Conference on Programming | |
8361 | Language Design and Implementation}, June 1998. | |
8362 | ||
8363 | @item [syntacticabstraction] | |
8364 | @pindex syntacticabstraction | |
8365 | R. Kent Dybvig, Robert Hieb, and Carl Bruggeman. | |
8366 | Syntactic abstraction in Scheme. | |
8367 | @emph{Lisp and Symbolic Computation} 5(4):295--326, 1993. | |
8368 | ||
8369 | @item [Scheme311] | |
8370 | @pindex Scheme311 | |
8371 | Carol Fessenden, William Clinger, Daniel P. Friedman, and Christopher Haynes. | |
8372 | Scheme 311 version 4 reference manual. | |
8373 | Indiana University Computer Science Technical Report 137, February 1983. | |
8374 | Superseded by [Scheme84]. | |
8375 | ||
8376 | @item [Scheme84] | |
8377 | @pindex Scheme84 | |
8378 | D. Friedman, C. Haynes, E. Kohlbecker, and M. Wand. | |
8379 | Scheme 84 interim reference manual. | |
8380 | Indiana University Computer Science Technical Report 153, January 1985. | |
8381 | ||
8382 | @item [IEEE] | |
8383 | @pindex IEEE | |
8384 | @emph{IEEE Standard 754-1985. IEEE Standard for Binary Floating-Point | |
8385 | Arithmetic.} IEEE, New York, 1985. | |
8386 | ||
8387 | @item [IEEEScheme] | |
8388 | @pindex IEEEScheme | |
8389 | @emph{IEEE Standard 1178-1990. IEEE Standard for the Scheme | |
8390 | Programming Language.} IEEE, New York, 1991. | |
8391 | ||
8392 | @item [Kohlbecker86] | |
8393 | @pindex Kohlbecker86 | |
8394 | Eugene E. Kohlbecker Jr. | |
8395 | @emph{Syntactic Extensions in the Programming Language Lisp.} | |
8396 | PhD thesis, Indiana University, August 1986. | |
8397 | ||
8398 | @item [hygienic] | |
8399 | @pindex hygienic | |
8400 | Eugene E. Kohlbecker Jr., Daniel P. Friedman, Matthias Felleisen, and Bruce Duba. | |
8401 | Hygienic macro expansion. | |
8402 | In @emph{Proceedings of the 1986 ACM Conference on Lisp | |
8403 | and Functional Programming}, pages 151--161. | |
8404 | ||
8405 | @item [Landin65] | |
8406 | @pindex Landin65 | |
8407 | Peter Landin. | |
8408 | A correspondence between Algol 60 and Church's lambda notation: Part I. | |
8409 | @emph{Communications of the ACM} 8(2):89--101, February 1965. | |
8410 | ||
8411 | @item [MITScheme] | |
8412 | @pindex MITScheme | |
8413 | MIT Department of Electrical Engineering and Computer Science. | |
8414 | Scheme manual, seventh edition. | |
8415 | September 1984. | |
8416 | ||
8417 | @item [Naur63] | |
8418 | @pindex Naur63 | |
8419 | Peter Naur et al. | |
8420 | Revised report on the algorithmic language Algol 60. | |
8421 | @emph{Communications of the ACM} 6(1):1--17, January 1963. | |
8422 | ||
8423 | @item [Penfield81] | |
8424 | @pindex Penfield81 | |
8425 | Paul Penfield, Jr. | |
8426 | Principal values and branch cuts in complex APL. | |
8427 | In @emph{APL '81 Conference Proceedings,} pages 248--256. | |
8428 | ACM SIGAPL, San Francisco, September 1981. | |
8429 | Proceedings published as @emph{APL Quote Quad} 12(1), ACM, September 1981. | |
8430 | ||
8431 | @item [Pitman83] | |
8432 | @pindex Pitman83 | |
8433 | Kent M. Pitman. | |
8434 | The revised MacLisp manual (Saturday evening edition). | |
8435 | MIT Laboratory for Computer Science Technical Report 295, May 1983. | |
8436 | ||
8437 | @item [Rees82] | |
8438 | @pindex Rees82 | |
8439 | Jonathan A. Rees and Norman I. Adams IV. | |
8440 | T: A dialect of Lisp or, lambda: The ultimate software tool. | |
8441 | In @emph{Conference Record of the 1982 ACM Symposium on Lisp and | |
8442 | Functional Programming}, pages 114--122. | |
8443 | ||
8444 | @item [Rees84] | |
8445 | @pindex Rees84 | |
8446 | Jonathan A. Rees, Norman I. Adams IV, and James R. Meehan. | |
8447 | The T manual, fourth edition. | |
8448 | Yale University Computer Science Department, January 1984. | |
8449 | ||
8450 | @item [R3RS] | |
8451 | @pindex R3RS | |
8452 | Jonathan Rees and William Clinger, editors. | |
8453 | The revised^3 report on the algorithmic language Scheme. | |
8454 | In @emph{ACM SIGPLAN Notices} 21(12), pages 37--79, December 1986. | |
8455 | ||
8456 | @item [Reynolds72] | |
8457 | @pindex Reynolds72 | |
8458 | John Reynolds. | |
8459 | Definitional interpreters for higher order programming languages. | |
8460 | In @emph{ACM Conference Proceedings}, pages 717--740. | |
8461 | ACM, | |
8462 | @ignore todo | |
8463 | month? | |
8464 | @end ignore | |
8465 | 1972. | |
8466 | ||
8467 | @item [Scheme78] | |
8468 | @pindex Scheme78 | |
8469 | Guy Lewis Steele Jr. and Gerald Jay Sussman. | |
8470 | The revised report on Scheme, a dialect of Lisp. | |
8471 | MIT Artificial Intelligence Memo 452, January 1978. | |
8472 | ||
8473 | @item [Rabbit] | |
8474 | @pindex Rabbit | |
8475 | Guy Lewis Steele Jr. | |
8476 | Rabbit: a compiler for Scheme. | |
8477 | MIT Artificial Intelligence Laboratory Technical Report 474, May 1978. | |
8478 | ||
8479 | @item [CLtL] | |
8480 | @pindex CLtL | |
8481 | Guy Lewis Steele Jr. | |
8482 | @emph{Common Lisp: The Language, second edition.} | |
8483 | Digital Press, Burlington MA, 1990. | |
8484 | ||
8485 | @item [Scheme75] | |
8486 | @pindex Scheme75 | |
8487 | Gerald Jay Sussman and Guy Lewis Steele Jr. | |
8488 | Scheme: an interpreter for extended lambda calculus. | |
8489 | MIT Artificial Intelligence Memo 349, December 1975. | |
8490 | ||
8491 | @item [Stoy77] | |
8492 | @pindex Stoy77 | |
8493 | Joseph E. Stoy. | |
8494 | @emph{Denotational Semantics: The Scott-Strachey Approach to | |
8495 | Programming Language Theory.} | |
8496 | MIT Press, Cambridge, 1977. | |
8497 | ||
8498 | @item [TImanual85] | |
8499 | @pindex TImanual85 | |
8500 | Texas Instruments, Inc. | |
8501 | TI Scheme Language Reference Manual. | |
8502 | Preliminary version 1.0, November 1985. | |
8503 | ||
8504 | @end itemize | |
8505 | ||
8506 | ||
8507 | ||
8508 | ||
8509 | @page | |
8510 | ||
8511 | ||
8512 | @c Adjustment to avoid having the last index entry on a page by itself. | |
8513 | @c \addtolength{\baselineskip}{-0.1pt} | |
8514 | ||
8515 | @node Index, , Bibliography, top | |
8516 | @unnumbered Alphabetic index of definitions of concepts, keywords, and procedures | |
8517 | ||
8518 | ||
8519 | ||
8520 | The principal entry for each term, procedure, or keyword is listed | |
8521 | first, separated from the other entries by a semicolon. | |
8522 | ||
8523 | @sp 6 | |
8524 | ||
8525 | @unnumberedsec Concepts | |
8526 | @printindex cp | |
8527 | @page | |
8528 | @unnumberedsec Procedures | |
8529 | @printindex fn | |
8530 | ||
8531 | @ifinfo | |
8532 | @unnumberedsec References | |
8533 | @printindex pg | |
8534 | @end ifinfo | |
8535 | ||
8536 | ||
8537 | @contents | |
8538 | @bye |