* Organize documentation into per-manual directories (halfway point commit).
[bpt/guile.git] / doc / r5rs / r5rs.texi
CommitLineData
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
122The report gives a defining description of the programming language
123Scheme. Scheme is a statically scoped and properly tail-recursive
124dialect of the Lisp programming language invented by Guy Lewis
125Steele Jr.@: and Gerald Jay Sussman. It was designed to have an
126exceptionally clear and simple semantics and few different ways to
127form expressions. A wide variety of programming paradigms, including
128imperative, functional, and message passing styles, find convenient
129expression in Scheme.
130
131The introduction offers a brief history of the language and of
132the report.
133
134The first three chapters present the fundamental ideas of the
135language and describe the notational conventions used for describing the
136language and for writing programs in the language.
137
138Chapters @ref{Expressions} and @ref{Program structure} describe
139the syntax and semantics of expressions, programs, and definitions.
140
141Chapter @ref{Standard procedures} describes Scheme's built-in
142procedures, which include all of the language's data manipulation and
143input/output primitives.
144
145Chapter @ref{Formal syntax and semantics} provides a formal syntax for Scheme
146written in extended BNF, along with a formal denotational semantics.
147An example of the use of the language follows the formal syntax and
148semantics.
149
150The report concludes with a list of references and an
151alphabetic index.
152
153@ignore todo
154expand 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
226The report gives a defining description of the programming language
227Scheme. Scheme is a statically scoped and properly tail-recursive
228dialect of the Lisp programming language invented by Guy Lewis
229Steele Jr.@: and Gerald Jay Sussman. It was designed to have an
230exceptionally clear and simple semantics and few different ways to
231form expressions. A wide variety of programming paradigms, including
232imperative, functional, and message passing styles, find convenient
233expression in Scheme.
234
235The introduction offers a brief history of the language and of
236the report.
237
238The first three chapters present the fundamental ideas of the
239language and describe the notational conventions used for describing the
240language and for writing programs in the language.
241
242Chapters @ref{Expressions} and @ref{Program structure} describe
243the syntax and semantics of expressions, programs, and definitions.
244
245Chapter @ref{Standard procedures} describes Scheme's built-in
246procedures, which include all of the language's data manipulation and
247input/output primitives.
248
249Chapter @ref{Formal syntax and semantics} provides a formal syntax for Scheme
250written in extended BNF, along with a formal denotational semantics.
251An example of the use of the language follows the formal syntax and
252semantics.
253
254The report concludes with a list of references and an
255alphabetic index.
256
257@ignore todo
258expand 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
316Programming languages should be designed not by piling feature on top of
317feature, but by removing the weaknesses and restrictions that make additional
318features appear necessary. Scheme demonstrates that a very small number
319of rules for forming expressions, with no restrictions on how they are
320composed, suffice to form a practical and efficient programming language
321that is flexible enough to support most of the major programming
322paradigms in use today.
323
324@c Scheme has influenced the evolution of Lisp.
325Scheme
326was one of the first programming languages to incorporate first class
327procedures as in the lambda calculus, thereby proving the usefulness of
328static scope rules and block structure in a dynamically typed language.
329Scheme was the first major dialect of Lisp to distinguish procedures
330from lambda expressions and symbols, to use a single lexical
331environment for all variables, and to evaluate the operator position
332of a procedure call in the same way as an operand position. By relying
333entirely on procedure calls to express iteration, Scheme emphasized the
334fact that tail-recursive procedure calls are essentially goto's that
335pass arguments. Scheme was the first widely used programming language to
336embrace first class escape procedures, from which all previously known
337sequential control structures can be synthesized. A subsequent
338version of Scheme introduced the concept of exact and inexact numbers,
339an extension of Common Lisp's generic arithmetic.
340More recently, Scheme became the first programming language to support
341hygienic macros, which permit the syntax of a block-structured language
342to 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
348Ramsdell:
349I would like to make a few comments on presentation. The most
350important comment is about section organization. Newspaper writers
351spend most of their time writing the first three paragraphs of any
352article. This part of the article is often the only part read by
353readers, and is important in enticing readers to continue. In the
354same way, The first page is most likely to be the only page read by
355many SIGPLAN readers. If I had my choice of what I would ask them to
356read, it would be the material in section 1.1, the Semantics section
357that notes that scheme is lexically scoped, tail recursive, weakly
358typed, ... etc. I would expand on the discussion on continuations,
359as they represent one important difference between Scheme and other
360languages. The introduction, with its history of scheme, its history
361of scheme reports and meetings, and acknowledgements giving names of
362people that the reader will not likely know, is not that one page I
363would like all to read. I suggest moving the history to the back of
364the report, and use the first couple of pages to convince the reader
365that 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
374The first description of Scheme was written in
3751975 [Scheme75]. A revised report [Scheme78]
376@ignore todo
377italicize or not?
378@end ignore
379 appeared in 1978, which described the evolution
380of the language as its MIT implementation was upgraded to support an
381innovative compiler [Rabbit]. Three distinct projects began in
3821981 and 1982 to use variants of Scheme for courses at MIT, Yale, and
383Indiana University [Rees82], [MITScheme], [Scheme311]. An introductory
384computer science textbook using Scheme was published in
3851984 [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
390As Scheme became more widespread,
391local dialects began to diverge until students and researchers
392occasionally found it difficult to understand code written at other
393sites.
394Fifteen representatives of the major implementations of Scheme therefore
395met in October 1984 to work toward a better and more widely accepted
396standard 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}
412Their report [RRRS]
413was published at MIT and Indiana University in the summer of 1985.
414Further 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.
417and in the spring of 1988 [R4RS].
418The present report reflects further revisions agreed upon in a meeting
419at 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
426Write an editors' note?
427@end ignore
428
429
430
431@sp 3
432
433We intend this report to belong to the entire Scheme community, and so
434we grant permission to copy it in whole or in part without fee. In
435particular, we encourage implementors of Scheme to use this report as
436a starting point for manuals and other documentation, modifying it as
437necessary.
438
439
440
441
442@node Acknowledgements, , Background, Introduction
443@unnumberedsec Acknowledgements
444
445
446We would like to thank the following people for their help: Alan Bawden, Michael
447Blair, George Carrette, Andy Cromarty, Pavel Curtis, Jeff Dalton, Olivier Danvy,
448Ken Dickey, Bruce Duba, Marc Feeley,
449Andy Freeman, Richard Gabriel, Yekta G"ursel, Ken Haase, Robert
450Hieb, Paul Hudak, Morry Katz, Chris Lindblad, Mark Meyer, Jim Miller, Jim Philbin,
451John Ramsdell, Mike Shaff, Jonathan Shapiro, Julie Sussman,
452Perry Wagle, Daniel Weise, Henry Wu, and Ozan Yigit.
453We thank Carol Fessenden, Daniel
454Friedman, and Christopher Haynes for permission to use text from the Scheme 311
455version 4 reference manual. We thank Texas Instruments, Inc. for permission to
456use text from the @emph{TI Scheme Language Reference Manual}[TImanual85].
457We gladly acknowledge the influence of manuals for MIT Scheme[MITScheme],
458T[Rees84], Scheme 84[Scheme84],Common Lisp[CLtL],
459and Algol 60[Naur63].
460
461We also thank Betty Dexter for the extreme effort she put into
462setting this report in @TeX{}, and Donald Knuth for designing the program
463that caused her troubles.
464
465The Artificial Intelligence Laboratory of the
466Massachusetts Institute of Technology, the Computer Science
467Department of Indiana University, the Computer and Information
468Sciences Department of the University of Oregon, and the NEC Research
469Institute supported the preparation of this report. Support for the MIT
470work was provided in part by
471the Advanced Research Projects Agency of the Department of Defense under Office
472of Naval Research contract N00014-80-C-0505. Support for the Indiana
473University work was provided by NSF grants NCS 83-04567 and NCS
47483-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
501This section gives an overview of Scheme's semantics. A
502detailed informal semantics is the subject of
503chapters @ref{Basic concepts} through @ref{Standard procedures}. For reference
504purposes, section @ref{Formal semantics} provides a formal
505semantics of Scheme.
506
507Following Algol, Scheme is a statically scoped programming
508language. Each use of a variable is associated with a lexically
509apparent binding of that variable.
510
511Scheme has latent as opposed to manifest types. Types
512are associated with values (also called objects) rather than
513@cindex @w{object}
514with variables. (Some authors refer to languages with latent types as
515weakly typed or dynamically typed languages.) Other languages with
516latent types are APL, Snobol, and other dialects of Lisp. Languages
517with manifest types (sometimes referred to as strongly typed or
518statically typed languages) include Algol 60, Pascal, and C.
519
520All objects created in the course of a Scheme computation, including
521procedures and continuations, have unlimited extent.
522No Scheme object is ever destroyed. The reason that
523implementations of Scheme do not (usually!) run out of storage is that
524they are permitted to reclaim the storage occupied by an object if
525they can prove that the object cannot possibly matter to any future
526computation. Other languages in which most objects have unlimited
527extent include APL and other Lisp dialects.
528
529Implementations of Scheme are required to be properly tail-recursive.
530This allows the execution of an iterative computation in constant space,
531even if the iterative computation is described by a syntactically
532recursive procedure. Thus with a properly tail-recursive implementation,
533iteration can be expressed using the ordinary procedure-call
534mechanics, so that special iteration constructs are useful only as
535syntactic sugar. See section @ref{Proper tail recursion}.
536
537Scheme procedures are objects in their own right. Procedures can be
538created dynamically, stored in data structures, returned as results of
539procedures, and so on. Other languages with these properties include
540Common Lisp and ML.
541@ignore todo
542Rozas: Scheme had them first.
543@end ignore
544
545
546One distinguishing feature of Scheme is that continuations, which
547in most other languages only operate behind the scenes, also have
548``first-class'' status. Continuations are useful for implementing a
549wide variety of advanced control constructs, including non-local exits,
550backtracking, and coroutines. See section @ref{Control features}.
551
552Arguments to Scheme procedures are always passed by value, which
553means that the actual argument expressions are evaluated before the
554procedure gains control, whether the procedure needs the result of the
555evaluation or not. ML, C, and APL are three other languages that always
556pass arguments by value.
557This is distinct from the lazy-evaluation semantics of Haskell,
558or the call-by-name semantics of Algol 60, where an argument
559expression is not evaluated unless its value is needed by the
560procedure.
561
562@ignore todo
563Lisp's call by value should be explained more
564accurately. What's funny is that all values are references.
565@end ignore
566
567
568Scheme's model of arithmetic is designed to remain as independent as
569possible of the particular ways in which numbers are represented within a
570computer. In Scheme, every integer is a rational number, every rational is a
571real, and every real is a complex number. Thus the distinction between integer
572and real arithmetic, so important to many programming languages, does not
573appear in Scheme. In its place is a distinction between exact arithmetic,
574which corresponds to the mathematical ideal, and inexact arithmetic on
575approximations. As in Common Lisp, exact arithmetic is not limited to
576integers.
577
578@node Syntax, Notation and terminology, Semantics, Overview of Scheme
579@section Syntax
580
581
582Scheme, like most dialects of Lisp, employs a fully parenthesized prefix
583notation for programs and (other) data; the grammar of Scheme generates a
584sublanguage of the language used for data. An important
585consequence of this simple, uniform representation is the susceptibility of
586Scheme programs and data to uniform treatment by other Scheme programs.
587For example, the @samp{eval} procedure evaluates a Scheme program expressed
588as data.
589
590The @samp{read} procedure performs syntactic as well as lexical decomposition of
591the data it reads. The @samp{read} procedure parses its input as data
592(section @pxref{External representation}), not as program.
593
594The 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
615It is required that every implementation of Scheme support all
616features that are not marked as being @dfn{optional}. Implementations are
617@cindex @w{optional}
618free to omit optional features of Scheme or to add extensions,
619provided the extensions are not in conflict with the language reported
620here. In particular, implementations must support portable code by
621providing a syntactic mode that preempts no lexical conventions of this
622report.
623
624To aid in understanding and implementing Scheme, some features are marked
625as @dfn{library}. These can be easily implemented in terms of the other,
626@cindex @w{library}
627primitive, features. They are redundant in the strict sense of
628the word, but they capture common patterns of usage, and are therefore
629provided 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}
637When speaking of an error situation, this report uses the phrase ``an
638error is signalled'' to indicate that implementations must detect and
639report the error. If such wording does not appear in the discussion of
640an error, then implementations are not required to detect or report the
641error, though they are encouraged to do so. An error situation that
642implementations are not required to detect is usually referred to simply
643as ``an error.''
644
645For example, it is an error for a procedure to be passed an argument that
646the procedure is not explicitly specified to handle, even though such
647domain errors are seldom mentioned in this report. Implementations may
648extend a procedure's domain of definition to include such arguments.
649
650This report uses the phrase ``may report a violation of an
651implementation restriction'' to indicate circumstances under which an
652implementation is permitted to report that it is unable to continue
653execution of a correct program because of some restriction imposed by the
654implementation. Implementation restrictions are of course discouraged,
655but implementations are encouraged to report violations of implementation
656restrictions.
657@cindex @w{implementation restriction}
658
659For example, an implementation may report a violation of an
660implementation restriction if it does not have enough storage to run a
661program.
662
663If the value of an expression is said to be ``unspecified,'' then
664the expression must evaluate to some object without signalling an error,
665but the value depends on the implementation; this report explicitly does
666not say what value should be returned.
667@cindex @w{unspecified}
668
669@ignore todo
670Talk about unspecified behavior vs. unspecified values.
671@end ignore
672
673
674@ignore todo
675Look 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
684Chapters @ref{Expressions} and @ref{Standard procedures} are organized
685into entries. Each entry describes one language feature or a group of
686related features, where a feature is either a syntactic construct or a
687built-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
695for required, primitive features, or
696
697
698@noindent
699@deffn {@var{qualifier} @var{category}} @var{template}
700
701@end deffn
702
703where @var{qualifier} is either ``library'' or ``optional'' as defined
704 in section @ref{Primitive; library; and optional features}.
705
706If @var{category} is ``syntax'', the entry describes an expression
707type, and the template gives the syntax of the expression type.
708Components of expressions are designated by syntactic variables, which
709are written using angle brackets, for example, @r{<expression>},
710@r{<variable>}. Syntactic variables should be understood to denote segments of
711program text; for example, @r{<expression>} stands for any string of
712characters which is a syntactically valid expression. The notation
713
714@format
715 @r{<thing1>} @dots{}
716@end format
717
718indicates zero or more occurrences of a @r{<thing>}, and
719
720@format
721 @r{<thing1>} @r{<thing2>} @dots{}
722@end format
723
724indicates one or more occurrences of a @r{<thing>}.
725
726If @var{category} is ``procedure'', then the entry describes a procedure, and
727the header line gives a template for a call to the procedure. Argument
728names 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
736indicates that the built-in procedure @t{vector-ref} takes
737two 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
750indicate that the @t{make-vector} procedure must be defined to take
751either one or two arguments.
752
753
754It is an error for an operation to be presented with an argument that it
755is not specified to handle. For succinctness, we follow the convention
756that if an argument name is also the name of a type listed in
757section @ref{Disjointness of types}, then that argument must be of the named type.
758For example, the header line for @t{vector-ref} given above dictates that the
759first argument to @t{vector-ref} must be a vector. The following naming
760conventions 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}
768any object
769@item @var{list}, @var{list1}, @dots{} @var{listj}, @dots{}
770list (see section @pxref{Pairs and lists})
771@item @var{z}, @var{z1}, @dots{} @var{zj}, @dots{}
772complex number
773@item @var{x}, @var{x1}, @dots{} @var{xj}, @dots{}
774real number
775@item @var{y}, @var{y1}, @dots{} @var{yj}, @dots{}
776real number
777@item @var{q}, @var{q1}, @dots{} @var{qj}, @dots{}
778rational number
779@item @var{n}, @var{n1}, @dots{} @var{nj}, @dots{}
780integer
781@item @var{k}, @var{k1}, @dots{} @var{kj}, @dots{}
782exact non-negative integer
783@item
784@end table
785@end quotation
786
787
788
789
790@ignore todo
791Provide 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
800The 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
811means that the expression @t{(* 5 8)} evaluates to the object @t{40}.
812Or, more precisely: the expression given by the sequence of characters
813``@t{(* 5 8)}'' evaluates, in the initial environment, to an object
814that may be represented externally by the sequence of characters ``@t{40}''. See section @ref{External representations} for a discussion of external
815representations of objects.
816
817@node Naming conventions, , Evaluation examples, Notation and terminology
818@subsection Naming conventions
819
820
821By convention, the names of procedures that always return a boolean
822value usually end
823in ``@code{?}''. Such procedures are called predicates.
824@vindex @w{?}
825
826By convention, the names of procedures that store values into previously
827allocated locations (see section @pxref{Storage model}) usually end in
828``@code{!}''.
829@vindex @w{!}
830Such procedures are called mutation procedures.
831By convention, the value returned by a mutation procedure is unspecified.
832
833By convention, ``@code{->}'' appears within the names of procedures that
834@vindex @w{->}
835take an object of one type and return an analogous object of another type.
836For example, @samp{list->vector} takes a list and returns a vector whose
837elements are the same as those of the list.
838
839
840
841@ignore todo
842Terms 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
861This section gives an informal account of some of the lexical
862conventions used in writing Scheme programs. For a formal syntax of
863Scheme, see section @ref{Formal syntax}.
864
865Upper and lower case forms of a letter are never distinguished
866except within character and string constants. For example, @samp{Foo} is
867the 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
875Most identifiers allowed by other programming
876@cindex @w{identifier}
877languages are also acceptable to Scheme. The precise rules for forming
878identifiers vary among implementations of Scheme, but in all
879implementations a sequence of letters, digits, and ``extended alphabetic
880characters'' that begins with a character that cannot begin a number is
881an identifier. In addition, @code{+}, @code{-}, and @code{...} are identifiers.
882@vindex @w{...}
883@vindex @w{-}
884@vindex @w{+}
885Here are some examples of identifiers:
886
887
888@example
889
890lambda q
891list->vector soup
892+ V17a
893<=? a34kTMNs
894the-word-recursion-has-many-meanings
895
896@end example
897
898
899Extended alphabetic characters may be used within identifiers as if
900they were letters. The following are extended alphabetic characters:
901
902
903@example
904
905! $ % & * + - . / : < = > ? @@ ^ _ ~
906@end example
907
908
909See section @ref{Lexical structure} for a formal syntax of identifiers.
910
911Identifiers have two uses within Scheme programs:
912
913
914@itemize @bullet
915
916@item
917Any identifier may be used as a variable
918or as a syntactic keyword
919(see sections @pxref{Variables; syntactic keywords; and regions} and @pxref{Macros}).
920
921@item
922When 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
960as tab or page break.) Whitespace is used for improved readability and
961as necessary to separate tokens from each other, a token being an
962indivisible lexical unit such as an identifier or number, but is
963otherwise insignificant. Whitespace may occur between any two tokens,
964but not within a token. Whitespace may also occur inside a string,
965where it is significant.
966
967A semicolon (@t{;}) indicates the start of a
968comment. The comment continues to the
969@cindex @w{;}
970@cindex @w{comment}
971end of the line on which the semicolon appears. Comments are invisible
972to Scheme, but the end of the line is visible as whitespace. This
973prevents a comment from appearing in the middle of an identifier or
974number.
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
996Rewrite?
997@end ignore
998
999
1000For a description of the notations used for numbers, see
1001section @ref{Numbers}.
1002
1003
1004@table @t
1005
1006
1007@item @t{.@: + -}
1008These are used in numbers, and may also occur anywhere in an identifier
1009except as the first character. A delimited plus or minus sign by itself
1010is also an identifier.
1011A delimited period (not occurring within a number or identifier) is used
1012in the notation for pairs (section @pxref{Pairs and lists}), and to indicate a
1013rest-parameter in a formal parameter list (section @pxref{Procedures}).
1014A delimited sequence of three successive periods is also an identifier.
1015
1016@item @t{( )}
1017Parentheses are used for grouping and to notate lists
1018(section @pxref{Pairs and lists}).
1019
1020@item @t{'}
1021The single quote character is used to indicate literal data (section @pxref{Literal expressions}).
1022
1023@item @t{`}
1024The backquote character is used to indicate almost-constant
1025data (section @pxref{Quasiquotation}).
1026
1027@item @t{, ,@@}
1028The character comma and the sequence comma at-sign are used in conjunction
1029with backquote (section @pxref{Quasiquotation}).
1030
1031@item @t{"}
1032The double quote character is used to delimit strings (section @pxref{Strings}).
1033
1034@item \
1035Backslash is used in the syntax for character constants
1036(section @pxref{Characters}) and as an escape character within string
1037constants (section @pxref{Strings}).
1038
1039@c A box used because \verb is not allowed in command arguments.
1040
1041@item @w{@t{[ ] @{ @} |}}
1042Left and right square brackets and curly braces and vertical bar
1043are reserved for possible future extensions to the language.
1044
1045@item #
1046 Sharp sign is used for a variety of purposes depending on
1047the character that immediately follows it:
1048
1049@item @t{#t} @t{#f}
1050These are the boolean constants (section @pxref{Booleans}).
1051
1052@item #\
1053This introduces a character constant (section @pxref{Characters}).
1054
1055@item #@t{(}
1056This introduces a vector constant (section @pxref{Vectors}). Vector constants
1057are terminated by @t{)} .
1058
1059@item @t{#e #i #b #o #d #x}
1060These 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
1087An identifier may name a type of syntax, or it may name
1088@cindex @w{identifier}
1089a location where a value can be stored. An identifier that names a type
1090of syntax is called a @emph{syntactic keyword}
1091@cindex @w{syntactic keyword}
1092and is said to be @emph{bound} to that syntax. An identifier that names a
1093location 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
1096bindings in effect at some point in a program is
1097@cindex @w{binding}
1098known as the @emph{environment} in effect at that point. The value
1099stored in the location to which a variable is bound is called the
1100variable's value. By abuse of terminology, the variable is sometimes
1101said to name the value or to be bound to the value. This is not quite
1102accurate, but confusion rarely results from this practice.
1103
1104@ignore todo
1105Define ``assigned'' and ``unassigned'' perhaps?
1106@end ignore
1107
1108
1109@ignore todo
1110In programs without side effects, one can safely pretend that the
1111variables are bound directly to the arguments. Or:
1112In programs without @code{set!}, one can safely pretend that the
1113@vindex @w{set!}
1114variable is bound directly to the value.
1115@end ignore
1116
1117
1118Certain expression types are used to create new kinds of syntax
1119and bind syntactic keywords to those new syntaxes, while other
1120expression types create new locations and bind variables to those
1121locations. These expression types are called @emph{binding constructs}.
1122
1123@cindex @w{binding construct}
1124Those that bind syntactic keywords are listed in section @ref{Macros}.
1125The most fundamental of the variable binding constructs is the
1126@samp{lambda} expression, because all other variable binding constructs
1127can be explained in terms of @samp{lambda} expressions. The other
1128variable binding constructs are @samp{let}, @samp{let*}, @samp{letrec},
1129and @samp{do} expressions (see sections @pxref{Procedures}, @pxref{Binding constructs}, and
1130@pxref{Iteration}).
1131
1132@c Note: internal definitions not mentioned here.
1133
1134Like Algol and Pascal, and unlike most other dialects of Lisp
1135except for Common Lisp, Scheme is a statically scoped language with
1136block structure. To each place where an identifier is bound in a program
1137there corresponds a @dfn{region} of the program text within which
1138@cindex @w{region}
1139the binding is visible. The region is determined by the particular
1140binding construct that establishes the binding; if the binding is
1141established by a @samp{lambda} expression, for example, then its region
1142is the entire @samp{lambda} expression. Every mention of an identifier
1143refers to the binding of the identifier that established the
1144innermost of the regions containing the use. If there is no binding of
1145the identifier whose region contains the use, then the use refers to the
1146binding for the variable in the top level environment, if any
1147(chapters @pxref{Expressions} and @pxref{Standard procedures}); if there is no
1148binding for the identifier,
1149it is said to be @dfn{unbound}.
1150@cindex @w{top level environment}
1151@cindex @w{bound}
1152@cindex @w{unbound}
1153
1154@ignore todo
1155Mention that some implementations have multiple top level environments?
1156@end ignore
1157
1158
1159@ignore todo
1160Pitman sez: needs elaboration in case of @t{(let ...)}
1161@end ignore
1162
1163
1164@ignore todo
1165Pitman asks: say something about vars created after scheme starts?
1166@t{(define x 3) (define (f) x) (define (g) y) (define y 4)}
1167Clinger replies: The language was explicitly
1168designed to permit a view in which no variables are created after
1169Scheme starts. In files, you can scan out the definitions beforehand.
1170I think we're agreed on the principle that interactive use should
1171approximate that behavior as closely as possible, though we don't yet
1172agree 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
1181No object satisfies more than one of the following predicates:
1182
1183
1184@example
1185
1186boolean? pair?
1187symbol? number?
1188char? string?
1189vector? port?
1190procedure?
1191
1192@end example
1193
1194
1195These 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
1196object 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
1212Although there is a separate boolean type,
1213any Scheme value can be used as a boolean value for the purpose of a
1214conditional test. As explained in section @ref{Booleans}, all
1215values 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.
1220This report uses the word ``true'' to refer to any
1221Scheme 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
1231An important concept in Scheme (and Lisp) is that of the @emph{external
1232representation} of an object as a sequence of characters. For example,
1233an external representation of the integer 28 is the sequence of
1234characters ``@t{28}'', and an external representation of a list consisting
1235of the integers 8 and 13 is the sequence of characters ``@t{(8 13)}''.
1236
1237The external representation of an object is not necessarily unique. The
1238integer 28 also has representations ``@t{#e28.000}'' and ``@t{#x1c}'', and the
1239list in the previous paragraph also has the representations ``@t{( 08 13
1240)}'' and ``@t{(8 .@: (13 .@: ()))}'' (see section @pxref{Pairs and lists}).
1241
1242Many objects have standard external representations, but some, such as
1243procedures, do not have standard representations (although particular
1244implementations may define representations for them).
1245
1246An external representation may be written in a program to obtain the
1247corresponding object (see @samp{quote}, section @pxref{Literal expressions}).
1248
1249External representations can also be used for input and output. The
1250procedure @samp{read} (section @pxref{Input}) parses external
1251representations, and the procedure @samp{write} (section @pxref{Output})
1252generates them. Together, they provide an elegant and powerful
1253input/output facility.
1254
1255Note that the sequence of characters ``@t{(+ 2 6)}'' is @emph{not} an
1256external representation of the integer 8, even though it @emph{is} an
1257expression evaluating to the integer 8; rather, it is an external
1258representation 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
1260any sequence of characters that is an expression is also the external
1261representation of some object. This can lead to confusion, since it may
1262not be obvious out of context whether a given sequence of characters is
1263intended to denote data or program, but it is also a source of power,
1264since it facilitates writing programs such as interpreters and
1265compilers that treat programs as data (or vice versa).
1266
1267The syntax of external representations of various kinds of objects
1268accompanies the description of the primitives for manipulating the
1269objects 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
1276Variables and objects such as pairs, vectors, and strings implicitly
1277denote locations or sequences of locations. A string, for
1278@cindex @w{location}
1279example, 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
1281stored into one of these locations using the @t{string-set!} procedure, but
1282the string continues to denote the same locations as before.
1283
1284An object fetched from a location, by a variable reference or by
1285a procedure such as @samp{car}, @samp{vector-ref}, or @samp{string-ref}, is
1286equivalent in the sense of @code{eqv?}
1287@c and \ide{eq?} ??
1288(section @pxref{Equivalence predicates})
1289@vindex @w{eqv?}
1290to the object last stored in the location before the fetch.
1291
1292Every location is marked to show whether it is in use.
1293No variable or object ever refers to a location that is not in use.
1294Whenever this report speaks of storage being allocated for a variable
1295or object, what is meant is that an appropriate number of locations are
1296chosen from the set of locations that are not in use, and the chosen
1297locations are marked to indicate that they are now in use before the variable
1298or object is made to denote them.
1299
1300In many systems it is desirable for constants (i.e. the values of
1301@cindex @w{constant}
1302literal expressions) to reside in read-only-memory. To express this, it is
1303convenient to imagine that every object that denotes locations is associated
1304with a flag telling whether that object is mutable or
1305@cindex @w{mutable}
1306immutable. In such systems literal constants and the strings
1307@cindex @w{immutable}
1308returned by @code{symbol->string} are immutable objects, while all objects
1309@vindex @w{symbol->string}
1310created by the other procedures listed in this report are mutable. It is an
1311error to attempt to store a new value into a location that is denoted by an
1312immutable object.
1313
1314@node Proper tail recursion, , Storage model, Basic concepts
1315@section Proper tail recursion
1316
1317
1318
1319Implementations of Scheme are required to be
1320@emph{properly tail-recursive}.
1321@cindex @w{proper tail recursion}
1322Procedure calls that occur in certain syntactic
1323contexts defined below are `tail calls'. A Scheme implementation is
1324properly tail-recursive if it supports an unbounded number of active
1325tail calls. A call is @emph{active} if the called procedure may still
1326return. Note that this includes calls that may be returned from either
1327by the current continuation or by continuations captured earlier by
1328@samp{call-with-current-continuation} that are later invoked.
1329In the absence of captured continuations, calls could
1330return at most once and the active calls would be those that had not
1331yet returned.
1332A formal definition of proper tail recursion can be found
1333in [propertailrecursion].
1334
1335
1336@quotation
1337@emph{Rationale:}
1338
1339Intuitively, no space is needed for an active tail call because the
1340continuation that is used in the tail call has the same semantics as the
1341continuation passed to the procedure containing the call. Although an improper
1342implementation might use a new continuation in the call, a return
1343to this new continuation would be followed immediately by a return
1344to the continuation passed to the procedure. A properly tail-recursive
1345implementation returns to that continuation directly.
1346
1347Proper tail recursion was one of the central ideas in Steele and
1348Sussman's original version of Scheme. Their first Scheme interpreter
1349implemented both functions and actors. Control flow was expressed using
1350actors, which differed from functions in that they passed their results
1351on to another actor instead of returning to a caller. In the terminology
1352of this section, each actor finished with a tail call to another actor.
1353
1354Steele and Sussman later observed that in their interpreter the code
1355for dealing with actors was identical to that for functions and thus
1356there was no need to include both in the language.
1357
1358@end quotation
1359
1360
1361A @emph{tail call} is a procedure call that occurs
1362@cindex @w{tail call}
1363in a @emph{tail context}. Tail contexts are defined inductively. Note
1364that a tail context is always determined with respect to a particular lambda
1365expression.
1366
1367
1368
1369@itemize @bullet
1370
1371@item
1372The last expression within the body of a lambda expression,
1373shown 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
1385If one of the following expressions is in a tail context,
1386then the subexpressions shown as <tail expression> are in a tail context.
1387These were derived from rules in the grammar given in
1388chapter @ref{Formal syntax and semantics} by replacing some occurrences of <expression>
1389with <tail expression>. Only those rules that contain tail contexts
1390are 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
1437If a @samp{cond} expression is in a tail context, and has a clause of
1438the form @samp{(@r{<expression1>} => @r{<expression2>})}
1439then the (implied) call to
1440the procedure that results from the evaluation of @r{<expression2>} is in a
1441tail context. @r{<expression2>} itself is not in a tail context.
1442
1443
1444@end itemize
1445
1446
1447Certain built-in procedures are also required to perform tail calls.
1448The 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}
1454Similarly, @code{eval} must evaluate its argument as if it
1455@vindex @w{eval}
1456were in tail position within the @code{eval} procedure.
1457@vindex @w{eval}
1458
1459In the following example the only tail call is the call to @samp{f}.
1460None 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
1462tail 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:}
1478Implementations are allowed, but not required, to
1479recognize that some non-tail calls, such as the call to @samp{h}
1480above, can be evaluated as though they were tail calls.
1481In the example above, the @samp{let} expression could be compiled
1482as a tail call to @samp{h}. (The possibility of @samp{h} returning
1483an unexpected number of values can be ignored, because in that
1484case the effect of the @samp{let} is explicitly unspecified and
1485implementation-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
1511Expression types are categorized as @emph{primitive} or @emph{derived}.
1512Primitive expression types include variables and procedure calls.
1513Derived expression types are not semantically primitive, but can instead
1514be defined as macros.
1515With the exception of @samp{quasiquote}, whose macro definition is complex,
1516the derived expressions are classified as library features.
1517Suitable 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
1541An expression consisting of a variable
1542@cindex @w{variable}
1543(section @pxref{Variables; syntactic keywords; and regions}) is a variable reference. The value of
1544the variable reference is the value stored in the location to which the
1545variable is bound. It is an error to reference an
1546unbound variable.
1547@cindex @w{unbound}
1548
1549
1550@format
1551@t{(define x 28)
1552x ==> 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>}
1575may be any external representation of a Scheme object (see
1576section @pxref{External representations}). This notation is used to include literal
1577constants 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
1591respects.
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
1605Numerical constants, string constants, character constants, and boolean
1606constants evaluate ``to themselves''; they need not be quoted.
1607
1608
1609@format
1610@t{'"abc" ==> "abc"
1611"abc" ==> "abc"
1612'145932 ==> 145932
1613145932 ==> 145932
1614'#t ==> #t
1615#t ==> #t
1616}
1617@end format
1618
1619
1620As 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
1635A procedure call is written by simply enclosing in parentheses
1636expressions for the procedure to be called and the arguments to be
1637passed to it. The operator and operand expressions are evaluated (in an
1638unspecified order) and the resulting procedure is passed the resulting
1639arguments.
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
1651A number of procedures are available as the values of variables in the
1652initial environment; for example, the addition and multiplication
1653procedures in the above examples are the values of the variables @samp{+}
1654and @samp{*}. New procedures are created by evaluating lambda expressions
1655(see section @pxref{Procedures}).
1656@ignore todo
1657At Friedman's request, flushed mention of other ways.
1658@end ignore
1659
1660@c or definitions (see section~\ref{define}).
1661
1662Procedure calls may return any number of values (see @code{values} in
1663@vindex @w{values}
1664section @pxref{Control features}). With the exception of @samp{values}
1665the procedures available in the initial environment return one
1666value or, for procedures such as @samp{apply}, pass on the values returned
1667by a call to one of their arguments.
1668
1669Procedure 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
1676evaluation is unspecified, and the operator expression and the operand
1677expressions are always evaluated with the same evaluation rules.
1678@end quotation
1679
1680
1681
1682@quotation
1683@emph{Note:}
1684Although the order of evaluation is otherwise unspecified, the effect of
1685any concurrent evaluation of the operator and operand expressions is
1686constrained to be consistent with some sequential order of evaluation.
1687The 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
1694least one subexpression, so @t{()} is not a syntactically valid
1695expression.
1696@ignore todo
1697Dybvig: ``it should be obvious from the syntax.''
1698@end ignore
1699
1700@end quotation
1701
1702
1703@ignore todo
1704Freeman:
1705I think an explanation as to why evaluation order is not specified
1706should be included. It should not include any reference to parallel
1707evaluation. Does any existing compiler generate better code because
1708the evaluation order is unspecified? Clinger: yes: T3, MacScheme v2,
1709probably MIT Scheme and Chez Scheme. But that's not the main reason
1710for 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,
1727and @r{<body>} should be a sequence of one or more expressions.
1728
1729@emph{Semantics:}
1730A lambda expression evaluates to a procedure. The environment in
1731effect when the lambda expression was evaluated is remembered as part of the
1732procedure. When the procedure is later called with some actual
1733arguments, the environment in which the lambda expression was evaluated will
1734be extended by binding the variables in the formal argument list to
1735fresh locations, the corresponding actual argument values will be stored
1736in those locations, and the expressions in the body of the lambda expression
1737will be evaluated sequentially in the extended environment.
1738The result(s) of the last expression in the body will be returned as
1739the 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{},)}:
1766The procedure takes a fixed number of arguments; when the procedure is
1767called, the arguments will be stored in the bindings of the
1768corresponding variables.
1769
1770@item
1771@r{<variable>}:
1772The procedure takes any number of arguments; when the procedure is
1773called, the sequence of actual arguments is converted into a newly
1774allocated 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>})}:
1780If a space-delimited period precedes the last variable, then
1781the procedure takes n or more arguments, where n is the
1782number of formal arguments before the period (there must
1783be at least one).
1784The value stored in the binding of the last variable will be a
1785newly allocated
1786list of the actual arguments left over after all the other actual
1787arguments have been matched up against the other formal arguments.
1788
1789@end itemize
1790
1791
1792It 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
1804Each procedure created as the result of evaluating a lambda expression is
1805(conceptually) tagged
1806with 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
1825expressions.
1826
1827@emph{Semantics:}
1828An @samp{if} expression is evaluated as follows: first,
1829@r{<test>} is evaluated. If it yields a true value (see
1830@cindex @w{true}
1831section @pxref{Booleans}), then @r{<consequent>} is evaluated and
1832its value(s) is(are) returned. Otherwise @r{<alternate>} is evaluated and its
1833value(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
1835unspecified.
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
1860the location to which @r{<variable>} is bound. @r{<Variable>} must
1861be bound either in some region enclosing the @samp{set!} expression
1862@cindex @w{region}
1863or at top level. The result of the @samp{set!} expression is
1864unspecified.
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
1893The constructs in this section are hygienic, as discussed in
1894section @ref{Macros}.
1895For reference purposes, section @ref{Derived expression type} gives macro definitions
1896that will convert most of the constructs described in this section
1897into the primitive constructs described in the previous section.
1898
1899@ignore todo
1900Mention 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:}
1912Each @r{<clause>} should be of the form
1913
1914@format
1915@t{(@r{<test>} @r{<expression1>} @dots{},)
1916}
1917@end format
1918
1919where @r{<test>} is any expression. Alternatively, a @r{<clause>} may be
1920of the form
1921
1922@format
1923@t{(@r{<test>} => @r{<expression>})
1924}
1925@end format
1926
1927The last @r{<clause>} may be
1928an ``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:}
1941A @samp{cond} expression is evaluated by evaluating the @r{<test>}
1942expressions of successive @r{<clause>}s in order until one of them
1943evaluates to a true value (see
1944@cindex @w{true}
1945section @pxref{Booleans}). When a @r{<test>} evaluates to a true
1946value, then the remaining @r{<expression>}s in its @r{<clause>} are
1947evaluated 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}
1949expression. 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{=>}
1954Its value must be a procedure that accepts one argument; this procedure is then
1955called on the value of the @r{<test>} and the value(s) returned by this
1956procedure is(are) returned by the @samp{cond} expression.
1957If all @r{<test>}s evaluate
1958to false values, and there is no else clause, then the result of
1959the conditional expression is unspecified; if there is an else
1960clause, then its @r{<expression>}s are evaluated, and the value(s) of
1961the 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
1987the form
1988
1989@format
1990@t{((@r{<datum1>} @dots{},) @r{<expression1>} @r{<expression2>} @dots{},)@r{,}
1991}
1992@end format
1993
1994where each @r{<datum>} is an external representation of some object.
1995All the @r{<datum>}s must be distinct.
1996The 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:}
2007A @samp{case} expression is evaluated as follows. @r{<Key>} is
2008evaluated and its result is compared against each @r{<datum>}. If the
2009result of evaluating @r{<key>} is equivalent (in the sense of
2010@samp{eqv?}; see section @pxref{Equivalence predicates}) to a @r{<datum>}, then the
2011expressions in the corresponding @r{<clause>} are evaluated from left
2012to right and the result(s) of the last expression in the @r{<clause>} is(are)
2013returned as the result(s) of the @samp{case} expression. If the result of
2014evaluating @r{<key>} is different from every @r{<datum>}, then if
2015there is an else clause its expressions are evaluated and the
2016result(s) of the last is(are) the result(s) of the @samp{case} expression;
2017otherwise 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
2041The @r{<test>} expressions are evaluated from left to right, and the
2042value of the first expression that evaluates to a false value (see
2043section @pxref{Booleans}) is returned. Any remaining expressions
2044are not evaluated. If all the expressions evaluate to true values, the
2045value of the last expression is returned. If there are no expressions
2046then @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
2064The @r{<test>} expressions are evaluated from left to right, and the value of the
2065first expression that evaluates to a true value (see
2066section @pxref{Booleans}) is returned. Any remaining expressions
2067are not evaluated. If all expressions evaluate to false values, the
2068value of the last expression is returned. If there are no
2069expressions 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
2089The three binding constructs @samp{let}, @samp{let*}, and @samp{letrec}
2090give Scheme a block structure, like Algol 60. The syntax of the three
2091constructs is identical, but they differ in the regions they establish
2092@cindex @w{region}
2093for their variable bindings. In a @samp{let} expression, the initial
2094values are computed before any of the variables become bound; in a
2095@samp{let*} expression, the bindings and evaluations are performed
2096sequentially; while in a @samp{letrec} expression, all the bindings are in
2097effect while their initial values are being computed, thus allowing
2098mutually 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
2111where each @r{<init>} is an expression, and @r{<body>} should be a
2112sequence of one or more expressions. It is
2113an error for a @r{<variable>} to appear more than once in the list of variables
2114being bound.
2115
2116@emph{Semantics:}
2117The @r{<init>}s are evaluated in the current environment (in some
2118unspecified order), the @r{<variable>}s are bound to fresh locations
2119holding the results, the @r{<body>} is evaluated in the extended
2120environment, and the value(s) of the last expression of @r{<body>}
2121is(are) returned. Each binding of a @r{<variable>} has @r{<body>} as its
2122region.
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
2138See 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
2155and @r{<body>} should be a sequence of
2156one or more expressions.
2157
2158@emph{Semantics:}
2159@samp{Let*} is similar to @samp{let}, but the bindings are performed
2160sequentially from left to right, and the region of a binding indicated
2161@cindex @w{region}
2162by @samp{(@r{<variable>} @r{<init>})} is that part of the @samp{let*}
2163expression to the right of the binding. Thus the second binding is done
2164in 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
2190and @r{<body>} should be a sequence of
2191one or more expressions. It is an error for a @r{<variable>} to appear more
2192than once in the list of variables being bound.
2193
2194@emph{Semantics:}
2195The @r{<variable>}s are bound to fresh locations holding undefined
2196values, the @r{<init>}s are evaluated in the resulting environment (in
2197some unspecified order), each @r{<variable>} is assigned to the result
2198of the corresponding @r{<init>}, the @r{<body>} is evaluated in the
2199resulting environment, and the value(s) of the last expression in
2200@r{<body>} is(are) returned. Each binding of a @r{<variable>} has the
2201entire @samp{letrec} expression as its region, making it possible to
2202@cindex @w{region}
2203define 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
2223One restriction on @samp{letrec} is very important: it must be possible
2224to 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
2226restriction is necessary because Scheme passes arguments by value rather than by
2227name. In the most common uses of @samp{letrec}, all the @r{<init>}s are
2228lambda 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
2242The @r{<expression>}s are evaluated sequentially from left to right,
2243and the value(s) of the last @r{<expression>} is(are) returned. This
2244expression type is used to sequence side effects such as input and
2245output.
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
2276be bound, how they are to be initialized at the start, and how they are
2277to be updated on each iteration. When a termination condition is met,
2278the loop exits after evaluating the @r{<expression>}s.
2279
2280@samp{Do} expressions are evaluated as follows:
2281The @r{<init>} expressions are evaluated (in some unspecified order),
2282the @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
2286Each iteration begins by evaluating @r{<test>}; if the result is
2287false (see section @pxref{Booleans}), then the @r{<command>}
2288expressions are evaluated in order for effect, the @r{<step>}
2289expressions 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
2294If @r{<test>} evaluates to a true value, then the
2295@r{<expression>}s are evaluated from left to right and the value(s) of
2296the last @r{<expression>} is(are) returned. If no @r{<expression>}s
2297are present, then the value of the @samp{do} expression is unspecified.
2298
2299The region of the binding of a @r{<variable>}
2300@cindex @w{region}
2301consists of the entire @samp{do} expression except for the @r{<init>}s.
2302It is an error for a @r{<variable>} to appear more than once in the
2303list of @samp{do} variables.
2304
2305A @r{<step>} may be omitted, in which case the effect is the
2306same as if @samp{(@r{<variable>} @r{<init>} @r{<variable>})} had
2307been 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}
2333a more general looping construct than @samp{do} and may also be used to express
2334recursions.
2335It has the same syntax and semantics as ordinary @samp{let}
2336except that @r{<variable>} is bound within @r{<body>} to a procedure
2337whose formal arguments are the bound variables and whose body is
2338@r{<body>}. Thus the execution of @r{<body>} may be repeated by
2339invoking 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
2372Fix.
2373@end ignore
2374
2375
2376The @samp{delay} construct is used together with the procedure @code{force} to
2377@vindex @w{force}
2378implement @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}
2384the @samp{force} procedure)
2385@ignore todo
2386Bartley's white lie; OK?
2387@end ignore
2388 to evaluate
2389@r{<expression>}, and deliver the resulting value.
2390The effect of @r{<expression>} returning multiple values
2391is unspecified.
2392
2393See the description of @samp{force} (section @pxref{Control features}) for a
2394more 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}
2412for constructing a list or vector structure when most but not all of the
2413desired structure is known in advance. If no
2414commas appear within the @r{<qq template>}, the result of
2415@cindex @w{comma}
2416evaluating
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
2421evaluated (``unquoted'') and its result is inserted into the structure
2422instead of the comma and the expression. If a comma appears followed
2423immediately by an at-sign (@@), then the following
2424@cindex @w{,@@}
2425expression must evaluate to a list; the opening and closing parentheses
2426of the list are then ``stripped away'' and the elements of the list are
2427inserted in place of the comma at-sign expression sequence. A comma
2428at-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
2447Quasiquote forms may be nested. Substitutions are made only for
2448unquoted components appearing at the same nesting level
2449as the outermost backquote. The nesting level increases by one inside
2450each successive quasiquotation, and decreases by one inside each
2451unquotation.
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
2465The 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>})}.
2471The external syntax generated by @code{write} for two-element lists whose
2472@vindex @w{write}
2473car 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
2488Unpredictable 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}
2493positions 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
2507Scheme programs can define and use new derived expression types,
2508 called @emph{macros}.
2509@cindex @w{macro}
2510Program-defined expression types have the syntax
2511
2512@example
2513
2514(@r{<keyword>} @r{<datum>} ...)
2515
2516@end example
2517
2518where @r{<keyword>} is an identifier that uniquely determines the
2519expression type. This identifier is called the @emph{syntactic
2520keyword}, or simply @emph{keyword}, of the macro. The
2521@cindex @w{macro keyword}
2522@cindex @w{keyword}
2523@cindex @w{syntactic keyword}
2524number of the @r{<datum>}s, and their syntax, depends on the
2525expression type.
2526
2527Each instance of a macro is called a @emph{use}
2528@cindex @w{macro use}
2529of the macro.
2530The set of rules that specifies
2531how a use of a macro is transcribed into a more primitive expression
2532is called the @emph{transformer}
2533@cindex @w{macro transformer}
2534of the macro.
2535
2536The macro definition facility consists of two parts:
2537
2538
2539
2540@itemize @bullet
2541
2542@item
2543A set of expressions used to establish that certain identifiers
2544are macro keywords, associate them with macro transformers, and control
2545the scope within which a macro is defined, and
2546
2547@item
2548a pattern language for specifying macro transformers.
2549
2550@end itemize
2551
2552
2553The syntactic keyword of a macro may shadow variable bindings, and local
2554variable bindings may shadow keyword bindings. All macros
2555@cindex @w{keyword}
2556defined using the pattern language are ``hygienic'' and ``referentially
2557transparent'' and thus preserve Scheme's lexical scoping [Kohlbecker86], [
2558hygienic], [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
2571If a macro transformer inserts a binding for an identifier
2572(variable or keyword), the identifier will in effect be renamed
2573throughout its scope to avoid conflicts with other identifiers.
2574Note that a @code{define} at top level may or may not introduce a binding;
2575see section @ref{Definitions}.
2576
2577@item
2578If a macro transformer inserts a free reference to an
2579identifier, the reference refers to the binding that was visible
2580where the transformer was specified, regardless of any local
2581bindings 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
2600analogous to @samp{let} and @samp{letrec}, but they bind
2601syntactic keywords to macro transformers instead of binding variables
2602to locations that contain values. Syntactic keywords may also be
2603bound 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
2616Each @r{<keyword>} is an identifier,
2617each @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
2619for a @r{<keyword>} to appear more than once in the list of keywords
2620being bound.
2621
2622@emph{Semantics:}
2623The @r{<body>} is expanded in the syntactic environment
2624obtained by extending the syntactic environment of the
2625@samp{let-syntax} expression with macros whose keywords are
2626the @r{<keyword>}s, bound to the specified transformers.
2627Each 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:}
2654Same as for @samp{let-syntax}.
2655
2656@emph{Semantics:}
2657 The @r{<body>} is expanded in the syntactic environment obtained by
2658extending the syntactic environment of the @samp{letrec-syntax}
2659expression with macros whose keywords are the
2660@r{<keyword>}s, bound to the specified transformers.
2661Each binding of a @r{<keyword>} has the @r{<bindings>}
2662as well as the @r{<body>} within its region,
2663so the transformers can
2664transcribe expressions into uses of the macros
2665introduced 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
2698A @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>}
2705should be of the form
2706
2707@format
2708@t{(@r{<pattern>} @r{<template>})
2709}
2710@end format
2711
2712The @r{<pattern>} in a @r{<syntax rule>} is a list @r{<pattern>}
2713that begins with the keyword for the macro.
2714
2715A @r{<pattern>} is either an identifier, a constant, or one of the
2716following
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
2727and 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
2736where an @r{<element>} is a @r{<template>} optionally
2737followed by an @r{<ellipsis>} and
2738an @r{<ellipsis>} is the identifier ``@samp{...}'' (which cannot be used as
2739an identifier in either a template or a pattern).
2740@vindex ...
2741
2742@emph{Semantics:} An instance of @samp{syntax-rules} produces a new macro
2743transformer by specifying a sequence of hygienic rewrite rules. A use
2744of 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>}.
2747When a match is found, the macro use is transcribed hygienically
2748according to the template.
2749
2750An identifier that appears in the pattern of a @r{<syntax rule>} is
2751a @emph{pattern variable}, unless it is the keyword that begins the pattern,
2752is listed in @r{<literals>}, or is the identifier ``@samp{...}''.
2753Pattern variables match arbitrary input elements and
2754are used to refer to elements of the input in the template. It is an
2755error for the same pattern variable to appear more than once in a
2756@r{<pattern>}.
2757
2758The keyword at the beginning of the pattern in a
2759@r{<syntax rule>} is not involved in the matching and
2760is not considered a pattern variable or literal identifier.
2761
2762
2763@quotation
2764@emph{Rationale:}
2765The scope of the keyword is determined by the expression or syntax
2766definition that binds it to the associated macro transformer.
2767If the keyword were a pattern variable or literal
2768identifier, then
2769the template that follows the pattern would be within its scope
2770regardless of whether the keyword were bound by @samp{let-syntax}
2771or by @samp{letrec-syntax}.
2772@end quotation
2773
2774
2775Identifiers that appear in @r{<literals>} are interpreted as literal
2776identifiers to be matched against corresponding subforms of the input.
2777A subform
2778in the input matches a literal identifier if and only if it is an
2779identifier
2780and either both its occurrence in the macro expression and its
2781occurrence in the macro definition have the same lexical binding, or
2782the 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
2788A subpattern followed by @samp{...} can match zero or more elements of the
2789input. It is an error for @samp{...} to appear in @r{<literals>}.
2790Within a pattern the identifier @samp{...} must follow the last element of
2791a nonempty sequence of subpatterns.
2792
2793More formally, an input form F matches a pattern P if and only if:
2794
2795
2796
2797@itemize @bullet
2798
2799@item
2800P is a non-literal identifier; or
2801
2802@item
2803P is a literal identifier and F is an identifier with the same
2804binding; or
2805
2806@item
2807P is a list @samp{(P_1 @dots{} P_n)} and F is a
2808list of n
2809forms that match P_1 through P_n, respectively; or
2810
2811@item
2812P is an improper list
2813@samp{(P_1 P_2 @dots{} P_n . P_n+1)}
2814and F is a list or
2815improper list of n or more forms that match P_1 through P_n,
2816respectively, and whose nth ``cdr'' matches P_n+1; or
2817
2818@item
2819P is of the form
2820@samp{(P_1 @dots{} P_n P_n+1 <ellipsis>)}
2821where <ellipsis> is the identifier @samp{...}
2822and F is
2823a proper list of at least n forms, the first n of which match
2824P_1 through P_n, respectively, and each remaining element of F
2825matches P_n+1; or
2826
2827@item
2828P is a vector of the form @samp{#(P_1 @dots{} P_n)}
2829and F is a vector
2830of n forms that match P_1 through P_n; or
2831
2832@item
2833P is of the form
2834@samp{#(P_1 @dots{} P_n P_n+1 <ellipsis>)}
2835where <ellipsis> is the identifier @samp{...}
2836and F is a vector of n
2837or more forms the first n of which match
2838P_1 through P_n, respectively, and each remaining element of F
2839matches P_n+1; or
2840
2841@item
2842P is a datum and F is equal to P in the sense of
2843the @samp{equal?} procedure.
2844
2845@end itemize
2846
2847
2848It is an error to use a macro keyword, within the scope of its
2849binding, in an expression that does not match any of the patterns.
2850
2851When a macro use is transcribed according to the template of the
2852matching @r{<syntax rule>}, pattern variables that occur in the
2853template are replaced by the subforms they match in the input.
2854Pattern variables that occur in subpatterns followed by one or more
2855instances of the identifier
2856@samp{...} are allowed only in subtemplates that are
2857followed by as many instances of @samp{...}.
2858They are replaced in the
2859output by all of the subforms they match in the input, distributed as
2860indicated. It is an error if the output cannot be built up as
2861specified.
2862
2863@c %% This description of output construction is very vague. It should
2864@c %% probably be formalized, but that is not easy...
2865
2866Identifiers that appear in the template but are not pattern variables
2867or the identifier
2868@samp{...} are inserted into the output as literal identifiers. If a
2869literal identifier is inserted as a free identifier then it refers to the
2870binding of that identifier within whose scope the instance of
2871@samp{syntax-rules} appears.
2872If a literal identifier is inserted as a bound identifier then it is
2873in effect renamed to prevent inadvertent captures of free identifiers.
2874
2875As an example, if @code{let} and @code{cond} are defined as in
2876@vindex @w{cond}
2877@vindex @w{let}
2878section @ref{Derived expression type} then they are hygienic (as required) and
2879the following is not an error.
2880
2881
2882@format
2883@t{(let ((=> #f))
2884 (cond (#t => 'ok))) ==> ok
2885}
2886@end format
2887
2888
2889The macro transformer for @samp{cond} recognizes @samp{=>}
2890as a local variable, and hence an expression, and not as the
2891top-level identifier @samp{=>}, which the macro transformer treats
2892as 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
2902instead of
2903
2904
2905@format
2906@t{(let ((=> #f))
2907 (let ((temp #t))
2908 (if temp ('ok temp))))
2909}
2910@end format
2911
2912
2913which 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
2936A Scheme program consists of a sequence of expressions, definitions,
2937and syntax definitions.
2938Expressions are described in chapter @ref{Expressions};
2939definitions and syntax definitions are the subject of the rest of the
2940present chapter.
2941
2942Programs are typically stored in files or entered interactively to a
2943running Scheme system, although other paradigms are possible;
2944questions of user interface lie outside the scope of this report.
2945(Indeed, Scheme would still be useful as a notation for expressing
2946computational methods even in the absence of a mechanical
2947implementation.)
2948
2949Definitions and syntax definitions occurring at the top level of a program
2950can be interpreted
2951declaratively.
2952They cause bindings to be created in the top level
2953environment or modify the value of existing top-level bindings.
2954Expressions occurring at the top level of a program are
2955interpreted imperatively; they are executed in order when the program is
2956invoked or loaded, and typically perform some kind of initialization.
2957
2958At the top level of a program @t{(begin @r{<form1>} @dots{},)} is
2959equivalent to the sequence of expressions, definitions, and syntax definitions
2960that form the body of the @code{begin}.
2961@vindex @w{begin}
2962
2963@ignore todo
2964Cromarty, 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
2978Definitions are valid in some, but not all, contexts where expressions
2979are allowed. They are valid only at the top level of a @r{<program>}
2980and at the beginning of a @r{<body>}.
2981
2982@cindex @w{definition}
2983
2984A 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
2997sequence of zero or more variables, or a sequence of one or more
2998variables followed by a space-delimited period and another variable (as
2999in 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
3012variable. 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
3030At the top level of a program, a definition
3031
3032@example
3033
3034(define @r{<variable>} @r{<expression>})
3035
3036@end example
3037
3038has essentially the same effect as the assignment expression
3039
3040@example
3041
3042(set! @r{<variable>} @r{<expression>})
3043
3044@end example
3045
3046if @r{<variable>} is bound. If @r{<variable>} is not bound,
3047however, then the definition will bind @r{<variable>} to a new
3048location before performing the assignment, whereas it would be an error
3049to 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
3064Some implementations of Scheme use an initial environment in
3065which all possible variables are bound to locations, most of
3066which contain undefined values. Top level definitions in
3067such an implementation are truly equivalent to assignments.
3068
3069@ignore todo
3070Rozas: 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
3080Definitions may occur at the
3081beginning 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}
3089expression or that of a definition of an appropriate form).
3090Such definitions are known as @emph{internal definitions} as opposed to the top level definitions described above.
3091@cindex @w{internal definition}
3092The variable defined by an internal definition is local to the
3093@r{<body>}. That is, @r{<variable>} is bound rather than assigned,
3094and 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
3107A @r{<body>} containing internal definitions can always be converted
3108into 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
3122Just as for the equivalent @samp{letrec} expression, it must be
3123possible to evaluate each @r{<expression>} of every internal
3124definition in a @r{<body>} without assigning or referring to
3125the value of any @r{<variable>} being defined.
3126
3127Wherever an internal definition may occur
3128@t{(begin @r{<definition1>} @dots{},)}
3129is equivalent to the sequence of definitions
3130that 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
3137Syntax definitions are valid only at the top level of a @r{<program>}.
3138
3139@cindex @w{syntax definition}
3140They 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
3146the @r{<transformer spec>} should be an instance of @code{syntax-rules}.
3147@vindex @w{syntax-rules}
3148The top-level syntactic environment is extended by binding the
3149@r{<keyword>} to the specified transformer.
3150
3151There 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
3172Although macros may expand into definitions and syntax definitions in
3173any context that permits them, it is an error for a definition or syntax
3174definition to shadow a syntactic keyword whose meaning is needed to
3175determine whether some form in the group of forms that contains the
3176shadowing definition is in fact a definition, or, for internal definitions,
3177is needed to determine the boundary between the group and the expressions
3178that 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
3230This chapter describes Scheme's built-in procedures. The initial (or
3231``top level'') Scheme environment starts out with a number of variables
3232bound to locations containing useful values, most of which are primitive
3233procedures that manipulate data. For example, the variable @samp{abs} is
3234bound to (a location initially containing) a procedure of one argument
3235that computes the absolute value of a number, and the variable @samp{+}
3236is bound to a procedure that computes sums. Built-in procedures that
3237can easily be written in terms of other built-in procedures are identified as
3238``library procedures''.
3239
3240A program may use a top-level definition to bind any variable. It may
3241subsequently alter any such binding by an assignment (see @pxref{Assignments}).
3242These operations do not modify the behavior of Scheme's built-in
3243procedures. Altering any top-level binding that has not been introduced by a
3244definition 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
3251A @dfn{predicate} is a procedure that always returns a boolean
3252@cindex @w{predicate}
3253value (@t{#t} or @t{#f}). An @dfn{equivalence predicate} is
3254@cindex @w{equivalence predicate}
3255the computational analogue of a mathematical equivalence relation (it is
3256symmetric, reflexive, and transitive). Of the equivalence predicates
3257described in this section, @samp{eq?} is the finest or most
3258discriminating, and @samp{equal?} is the coarsest. @samp{Eqv?} is
3259slightly less discriminating than @samp{eq?}.
3260@ignore todo
3261Pitman doesn't like
3262this paragraph. Lift the discussion from the Maclisp manual. Explain
3263why there's more than one predicate.
3264@end ignore
3265
3266
3267
3268
3269@deffn {procedure} eqv? obj1 obj2
3270
3271The @samp{eqv?} procedure defines a useful equivalence relation on objects.
3272Briefly, it returns @t{#t} if @var{obj1} and @var{obj2} should
3273normally be regarded as the same object. This relation is left slightly
3274open to interpretation, but the following partial specification of
3275@samp{eqv?} holds for all implementations of Scheme.
3276
3277The @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:}
3301This assumes that neither @var{obj1} nor @var{obj2} is an ``uninterned
3302symbol'' as alluded to in section @ref{Symbols}. This report does
3303not presume to specify the behavior of @samp{eqv?} on implementation-dependent
3304extensions.
3305@end quotation
3306
3307
3308@item
3309@var{obj1} and @var{obj2} are both numbers, are numerically
3310equal (see @samp{=}, section @pxref{Numbers}), and are either both
3311exact or both inexact.
3312
3313@item
3314@var{obj1} and @var{obj2} are both characters and are the same
3315character according to the @samp{char=?} procedure
3316(section @pxref{Characters}).
3317
3318@item
3319both @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
3323same locations in the store (section @pxref{Storage model}).
3324
3325@item
3326@var{obj1} and @var{obj2} are procedures whose location tags are
3327equal (section @pxref{Procedures}).
3328
3329@end itemize
3330
3331@cindex @w{inexact}
3332@cindex @w{exact}
3333
3334The @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
3345one 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
3361one of @var{obj1} and @var{obj2} is an exact number but the other
3362is an inexact number.
3363
3364@item
3365@var{obj1} and @var{obj2} are numbers for which the @samp{=}
3366procedure returns @t{#f}.
3367
3368@item
3369@var{obj1} and @var{obj2} are characters for which the @samp{char=?}
3370procedure returns @t{#f}.
3371
3372@item
3373one of @var{obj1} and @var{obj2} is the empty list but the other
3374is not.
3375
3376@item
3377@var{obj1} and @var{obj2} are pairs, vectors, or strings that denote
3378distinct 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
3405The following examples illustrate cases in which the above rules do
3406not fully specify the behavior of @samp{eqv?}. All that can be said
3407about such cases is that the value returned by @samp{eqv?} must be a
3408boolean.
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
3422The next set of examples shows the use of @samp{eqv?} with procedures
3423that have local state. @samp{Gen-counter} must return a distinct
3424procedure every time, since each procedure has its own internal counter.
3425@samp{Gen-loser}, however, returns equivalent procedures each time, since
3426the local state does not affect the value or side effects of the
3427procedures.
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
3469Since it is an error to modify constant objects (those returned by
3470literal expressions), implementations are permitted, though not
3471required, to share structure between constants where appropriate. Thus
3472the value of @samp{eqv?} on constants is sometimes
3473implementation-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:}
3489The above definition of @samp{eqv?} allows implementations latitude in
3490their treatment of procedures and literals: implementations are free
3491either to detect or to fail to detect that two procedures or two literals
3492are equivalent to each other, and can decide whether or not to
3493merge representations of equivalent objects by using the same pointer or
3494bit 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
3505capable of discerning distinctions finer than those detectable by
3506@samp{eqv?}.
3507
3508@samp{Eq?} and @samp{eqv?} are guaranteed to have the same
3509behavior on symbols, booleans, the empty list, pairs, procedures,
3510and non-empty
3511strings and vectors. @samp{Eq?}'s behavior on numbers and characters is
3512implementation-dependent, but it will always return either true or
3513false, and will return true only when @samp{eqv?} would also return
3514true. @samp{Eq?} may also behave differently from @samp{eqv?} on empty
3515vectors 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
3541Needs to be explained better above. How can this be made to be
3542not 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
3549more efficiently than @samp{eqv?}, for example, as a simple pointer
3550comparison instead of as some more complicated operation. One reason is
3551that it may not be possible to compute @samp{eqv?} of two numbers in
3552constant time, whereas @samp{eq?} implemented as pointer comparison will
3553always finish in constant time. @samp{Eq?} may be used like @samp{eqv?}
3554in applications using procedures to implement objects with state since
3555it 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
3566strings, applying @samp{eqv?} on other objects such as numbers and symbols.
3567A rule of thumb is that objects are generally @samp{equal?} if they print
3568the same. @samp{Equal?} may fail to terminate if its arguments are
3569circular 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
3616Numerical computation has traditionally been neglected by the Lisp
3617community. Until Common Lisp there was no carefully thought out
3618strategy for organizing numerical computation, and with the exception of
3619the MacLisp system [Pitman83] little effort was made to
3620execute numerical code efficiently. This report recognizes the excellent work
3621of the Common Lisp committee and accepts many of their recommendations.
3622In some ways this report simplifies and generalizes their proposals in a manner
3623consistent with the purposes of Scheme.
3624
3625It is important to distinguish between the mathematical numbers, the
3626Scheme numbers that attempt to model them, the machine representations
3627used to implement the Scheme numbers, and notations used to write numbers.
3628This report uses the types @i{number}, @i{complex}, @i{real},
3629@i{rational}, and @i{integer} to refer to both mathematical numbers
3630and Scheme numbers. Machine representations such as fixed point and
3631floating 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
3660Mathematically, numbers may be arranged into a tower of subtypes
3661@c %R4%% with injections relating adjacent levels of the tower:
3662in 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
3673For example, 3 is an integer. Therefore 3 is also a rational,
3674a real, and a complex. The same is true of the Scheme numbers
3675that model 3. For Scheme numbers, these types are defined by the
3676predicates @code{number?}, @code{complex?}, @code{real?}, @code{rational?},
3677@vindex @w{rational?}
3678@vindex @w{real?}
3679@vindex @w{complex?}
3680@vindex @w{number?}
3681and @code{integer?}.
3682@vindex @w{integer?}
3683
3684There is no simple relationship between a number's type and its
3685representation inside a computer. Although most implementations of
3686Scheme will offer at least two different representations of 3, these
3687different 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
3692Scheme's numerical operations treat numbers as abstract data, as
3693independent of their representation as possible. Although an implementation
3694of Scheme may use fixnum, flonum, and perhaps other representations for
3695numbers, this should not be apparent to a casual programmer writing
3696simple programs.
3697
3698It is necessary, however, to distinguish between numbers that are
3699represented exactly and those that may not be. For example, indexes
3700into data structures must be known exactly, as must some polynomial
3701coefficients in a symbolic algebra system. On the other hand, the
3702results of measurements are inherently inexact, and irrational numbers
3703may be approximated by rational and therefore inexact approximations.
3704In order to catch uses of inexact numbers where exact numbers are
3705required, Scheme explicitly distinguishes exact from inexact numbers.
3706This 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}
3718Scheme 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,
3723if it was
3724derived using @r{inexact} ingredients, or if it was derived using
3725@r{inexact} operations. Thus @r{inexact}ness is a contagious
3726property of a number.
3727@c %R4%% The rest of this paragraph (from R3RS) has been dropped.
3728
3729If two implementations produce @r{exact} results for a
3730computation that did not involve @r{inexact} intermediate results,
3731the two ultimate results will be mathematically equivalent. This is
3732generally not true of computations involving @r{inexact} numbers
3733since approximate methods such as floating point arithmetic may be used,
3734but it is the duty of each implementation to make the result as close as
3735practical to the mathematically ideal result.
3736
3737Rational 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)
3742If the operation is unable to produce an @r{exact} result,
3743then it may either report the violation of an implementation restriction
3744or it may silently coerce its
3745result to an @r{inexact} value.
3746@c %R4%%Such a coercion may cause an error later.
3747See section @ref{Implementation restrictions}.
3748
3749With the exception of @code{inexact->exact}, the operations described in
3750@vindex @w{inexact->exact}
3751this section must generally return inexact results when given any inexact
3752arguments. An operation may, however, return an @r{exact} result if it can
3753prove that the value of the result is unaffected by the inexactness of its
3754arguments. For example, multiplication of any number by an @r{exact} zero
3755may 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
3765Implementations of Scheme are not required to implement the whole
3766tower of subtypes given in section @ref{Numerical types},
3767but they must implement a coherent subset consistent with both the
3768purposes of the implementation and the spirit of the Scheme language.
3769For example, an implementation in which all numbers are @r{real}
3770may still be quite useful.
3771
3772Implementations may also support only a limited range of numbers of
3773any type, subject to the requirements of this section. The supported
3774range for @r{exact} numbers of any type may be different from the
3775supported range for @r{inexact} numbers of that type. For example,
3776an implementation that uses flonums to represent all its
3777@r{inexact} @r{real} numbers may
3778support a practically unbounded range of @r{exact} @r{integer}s
3779and @r{rational}s
3780while limiting the range of @r{inexact} @r{real}s (and therefore
3781the range of @r{inexact} @r{integer}s and @r{rational}s)
3782to the dynamic range of the flonum format.
3783Furthermore
3784the gaps between the representable @r{inexact} @r{integer}s and
3785@r{rational}s are
3786likely to be very large in such an implementation as the limits of this
3787range are approached.
3788
3789An implementation of Scheme must support exact integers
3790throughout the range of numbers that may be used for indexes of
3791lists, vectors, and strings or that may result from computing the length of a
3792list, vector, or string. The @code{length}, @code{vector-length},
3793@vindex @w{vector-length}
3794@vindex @w{length}
3795and @code{string-length} procedures must return an exact
3796@vindex @w{string-length}
3797integer, and it is an error to use anything but an exact integer as an
3798index. Furthermore any integer constant within the index range, if
3799expressed by an exact integer syntax, will indeed be read as an exact
3800integer, regardless of any implementation restrictions that may apply
3801outside this range. Finally, the procedures listed below will always
3802return an exact integer result provided all their arguments are exact integers
3803and the mathematically expected result is representable as an exact integer
3804within the implementation:
3805
3806
3807@example
3808
3809+ - *
3810quotient remainder modulo
3811max min abs
3812numerator denominator gcd
3813lcm floor ceiling
3814truncate round rationalize
3815expt
3816
3817@end example
3818
3819
3820Implementations are encouraged, but not required, to support
3821@r{exact} @r{integer}s and @r{exact} @r{rational}s of
3822practically unlimited size and precision, and to implement the
3823above procedures and the @samp{/} procedure in
3824such a way that they always return @r{exact} results when given @r{exact}
3825arguments. If one of these procedures is unable to deliver an @r{exact}
3826result when given @r{exact} arguments, then it may either report a
3827violation of an
3828implementation 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
3850An implementation may use floating point and other approximate
3851representation 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
3860This report recommends, but does not require, that the IEEE 32-bit
3861and 64-bit floating point standards be followed by implementations that use
3862flonum representations, and that implementations using
3863other representations should match or exceed the precision achievable
3864using these floating point standards [IEEE].
3865
3866In particular, implementations that use flonum representations
3867must follow these rules: A @r{flonum} result
3868must be represented with at least as much precision as is used to express any of
3869the inexact arguments to that operation. It is desirable (but not required) for
3870potentially inexact operations such as @samp{sqrt}, when applied to @r{exact}
3871arguments, to produce @r{exact} answers whenever possible (for example the
3872square root of an @r{exact} 4 ought to be an @r{exact} 2).
3873If, 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
3876the most precise @r{flonum} format available must be used; but if the result
3877is represented in some other way then the representation must have at least as
3878much precision as the most precise @r{flonum} format available.
3879
3880Although Scheme allows a variety of written
3881@c %R4%% representations of
3882notations for
3883numbers, any particular implementation may support only some of them.
3884@c %R4%%
3885For example, an implementation in which all numbers are @r{real}
3886need not support the rectangular and polar notations for complex
3887numbers. If an implementation encounters an @r{exact} numerical constant that
3888it cannot represent as an @r{exact} number, then it may either report a
3889violation of an implementation restriction or it may silently represent the
3890constant 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
3913The syntax of the written representations for numbers is described formally in
3914section @ref{Lexical structure}. Note that case is not significant in numerical
3915constants.
3916
3917@c %R4%% See section~\ref{numberformats} for many examples.
3918
3919A number may be written in binary, octal, decimal, or
3920hexadecimal 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
3925no radix prefix, a number is assumed to be expressed in decimal.
3926
3927A
3928@c %R4%%
3929@c simple
3930numerical constant may be specified to be either @r{exact} or
3931@r{inexact} by a prefix. The prefixes are @samp{#e}
3932@vindex #e
3933for @r{exact}, and @samp{#i} for @r{inexact}. An exactness
3934@vindex #i
3935prefix may appear before or after any radix prefix that is used. If
3936the written representation of a number has no exactness prefix, the
3937constant may be either @r{inexact} or @r{exact}. It is
3938@r{inexact} if it contains a decimal point, an
3939exponent, or a ``#'' character in the place of a digit,
3940otherwise 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
3947In systems with @r{inexact} numbers
3948of varying precisions it may be useful to specify
3949the precision of a constant. For this purpose, numerical constants
3950may be written with an exponent marker that indicates the
3951desired precision of the @r{inexact}
3952representation. 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
3955than four internal
3956@c %R4%%\tupe{flonum}
3957@r{inexact}
3958representations exist, the four size
3959specifications are mapped onto those available. For example, an
3960implementation with two internal representations may map short and
3961single together and long and double together.) In addition, the
3962exponent marker @samp{e} specifies the default precision for the
3963implementation. The default precision has at least as much precision
3964as @var{double}, but
3965implementations may wish to allow this default to be set by the user.
3966
3967
3968@example
3969
39703.14159265358979F0
3971 @r{Round to single ---} 3.141593
39720.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
3983The reader is referred to section @ref{Entry format} for a summary
3984of the naming conventions used to specify restrictions on the types of
3985arguments 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.
3992The examples used in this section assume that any numerical constant written
3993using an @r{exact} notation is indeed represented as an @r{exact}
3994number. Some examples also assume that certain numerical constants written
3995using an @r{inexact} notation can be represented without loss of
3996accuracy; the @r{inexact} constants were chosen so that this is
3997likely to be true in implementations that use flonums to represent
3998inexact numbers.
3999
4000@ignore todo
4001Scheme provides the usual set of operations for manipulating
4002numbers, 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
4013These numerical type predicates can be applied to any kind of
4014argument, including non-numbers. They return @t{#t} if the object is
4015of the named type, and otherwise they return @t{#f}.
4016In general, if a type predicate is true of a number then all higher
4017type predicates are also true of that number. Consequently, if a type
4018predicate is false of a number, then all lower type predicates are
4019also 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
4026If @var{z} is an inexact complex number, then @samp{(real? @var{z})} is true if
4027and only if @samp{(zero? (imag-part @var{z}))} is true. If @var{x} is an inexact
4028real 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:}
4050The behavior of these type predicates on @r{inexact} numbers
4051is unreliable, since any inaccuracy may affect the result.
4052@end quotation
4053
4054
4055
4056@quotation
4057@emph{Note:}
4058In many implementations the @code{rational?} procedure will be the same
4059@vindex @w{rational?}
4060as @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?}
4065some irrational numbers exactly or may extend the number system to
4066support 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
4076These numerical predicates provide tests for the exactness of a
4077quantity. For any Scheme number, precisely one of these predicates
4078is 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.
4092These procedures return @t{#t} if their arguments are (respectively):
4093equal, monotonically increasing, monotonically decreasing,
4094monotonically nondecreasing, or monotonically nonincreasing.
4095
4096These predicates are required to be transitive.
4097
4098
4099@quotation
4100@emph{Note:}
4101The traditional implementations of these predicates in Lisp-like
4102languages are not transitive.
4103@end quotation
4104
4105
4106
4107@quotation
4108@emph{Note:}
4109While it is not an error to compare @r{inexact} numbers using these
4110predicates, the results may be unreliable because a small inaccuracy
4111may affect the result; this is especially true of @code{=} and @code{zero?}.
4112@vindex @w{zero?}
4113@vindex @w{=}
4114When 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
4127These numerical predicates test a number for a particular property,
4128returning @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
4136These 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:}
4149If any argument is inexact, then the result will also be inexact (unless
4150the procedure can prove that the inaccuracy is not large enough to affect the
4151result, 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
4153value of the result cannot be represented as an inexact number without loss of
4154accuracy, then the procedure may report a violation of an implementation
4155restriction.
4156@end quotation
4157
4158
4159@end deffn
4160
4161
4162
4163@deffn {procedure} + z1 @dots{},
4164@deffnx {procedure} * z1 @dots{},
4165
4166These 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
4191With two or more arguments, these procedures return the difference or
4192quotient of their arguments, associating to the left. With one argument,
4193however, 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
4231These procedures implement number-theoretic (integer)
4232division. @var{n2} should be non-zero. All three procedures
4233return 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
4242If @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
4251where @var{n_q} is @var{n1}/@var{n2} rounded towards zero,
42520 < |@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
4257From 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
4267provided 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
4293These procedures return the greatest common divisor or least common
4294multiple 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
4316These procedures return the numerator or denominator of their
4317argument; the result is computed as if the argument was represented as
4318a fraction in lowest terms. The denominator is always positive. The
4319denominator 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
4324More 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
4347These 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
4351value is not larger than the absolute value of @var{x}. @samp{Round} returns the
4352closest integer to @var{x}, rounding to even when @var{x} is halfway between two
4353integers.
4354
4355
4356@quotation
4357@emph{Rationale:}
4358@samp{Round} rounds to even for consistency with the default rounding
4359mode specified by the IEEE floating point standard.
4360@end quotation
4361
4362
4363
4364@quotation
4365@emph{Note:}
4366If the argument to one of these procedures is inexact, then the result
4367will also be inexact. If an exact value is needed, the
4368result 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
4398differing 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}
4401r_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.
4402Although not all rationals are comparable in this ordering (consider 2/7
4403and 3/5) any interval contains a rational number that is simpler than
4404every other rational number in that interval (the simpler 2/5 lies
4405between 2/7 and 3/5). Note that 0 = 0/1 is the simplest rational of
4406all.
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
4430These procedures are part of every implementation that supports
4431@c %R4%%
4432general
4433real numbers; they compute the usual transcendental functions. @samp{Log}
4434computes the natural logarithm of @var{z} (not the base ten logarithm).
4435@samp{Asin}, @samp{acos}, and @samp{atan} compute arcsine (sin^-1),
4436arccosine (cos^-1), and arctangent (tan^-1), respectively.
4437The two-argument variant of @samp{atan} computes @t{(angle
4438(make-rectangular @var{x} @var{y}))} (see below), even in implementations
4439that don't support general complex numbers.
4440
4441In general, the mathematical functions log, arcsine, arccosine, and
4442arctangent are multiply defined.
4443The value of log z is defined to be the one whose imaginary
4444part lies in the range from -pi (exclusive) to pi (inclusive).
4445log 0 is undefined.
4446With log defined this way, the values of sin^-1 z, cos^-1 z,
4447and 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
4461The above specification follows [CLtL], which in turn
4462cites [Penfield81]; refer to these sources for more detailed
4463discussion of branch cuts, boundary conditions, and implementation of
4464these functions. When it is possible these procedures produce a real
4465result from a real argument.
4466
4467@c %R4%%
4468
4469@ignore todo
4470The cited references are likely to change their branch cuts
4471soon to allow for the possibility of distinct positive and negative
4472zeroes, as in IEEE floating point. We may not want to follow those
4473changes, 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
4475think there are any better standards for complex arithmetic than the
4476ones 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
4486Returns the principal square root of @var{z}. The result will have
4487either positive real part, or zero real part and non-negative imaginary
4488part.
4489@end deffn
4490
4491
4492
4493@deffn {procedure} expt z1 z2
4494
4495Returns @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
45000^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
4533These procedures are part of every implementation that supports
4534@c %R4%%
4535general
4536complex numbers. Suppose @var{x1}, @var{x2}, @var{x3}, and @var{x4} are
4537real 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
4542Then
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
4554where -pi < x_angle <= pi with x_angle = @var{x4} + 2pi n
4555for 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}
4562but @samp{abs} must be present in all implementations, whereas
4563@samp{magnitude} need only be present in implementations that support
4564general 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}.
4576The 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.
4581If an @r{exact} argument has no reasonably close @r{inexact} equivalent,
4582then 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
4586closest 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.
4590If an @r{inexact} argument has no reasonably close @r{exact} equivalent,
4591then 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
4603These procedures implement the natural one-to-one correspondence between
4604@r{exact} and @r{inexact} integers throughout an
4605implementation-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.
4621The procedure @samp{number->string} takes a
4622number and a radix and returns as a string an external representation of
4623the 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
4635is true. It is an error if no possible result makes this expression true.
4636
4637If @var{z} is inexact, the radix is 10, and the above expression
4638can be satisfied by a result that contains a decimal point,
4639then the result contains a decimal point and is expressed using the
4640minimum number of digits (exclusive of exponent and trailing
4641zeroes) needed to make the above expression
4642true [howtoprint], [howtoread];
4643otherwise the format of the result is unspecified.
4644
4645The result returned by @samp{number->string}
4646never contains an explicit radix prefix.
4647
4648
4649@quotation
4650@emph{Note:}
4651The error case can occur only when @var{z} is not a complex number
4652or is a complex number with a non-rational real or imaginary part.
4653@end quotation
4654
4655
4656
4657@quotation
4658@emph{Rationale:}
4659If @var{z} is an inexact number represented using flonums, and
4660the radix is 10, then the above expression is normally satisfied by
4661a result containing a decimal point. The unspecified case
4662allows 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
4677Returns a number of the maximally precise representation expressed by the
4678given @var{string}. @var{Radix} must be an exact integer, either 2, 8, 10,
4679or 16. If supplied, @var{radix} is a default radix that may be overridden
4680by an explicit radix prefix in @var{string} (e.g. @t{"#o177"}). If @var{radix}
4681is not supplied, then the default radix is 10. If @var{string} is not
4682a syntactically valid notation for a number, then @samp{string->number}
4683returns @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:}
4698The domain of @samp{string->number} may be restricted by implementations
4699in the following ways. @samp{String->number} is permitted to return
4700@t{#f} whenever @var{string} contains an explicit radix prefix.
4701If 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
4704numbers. If all numbers are integers, then
4705@samp{string->number} may return @t{#f} whenever
4706the fractional notation is used. If all numbers are exact, then
4707@samp{string->number} may return @t{#f} whenever
4708an exponent marker or explicit exactness prefix is used, or if
4709a @t{#} appears in place of a digit. If all inexact
4710numbers are integers, then
4711@samp{string->number} may return @t{#f} whenever
4712a 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
4731This section describes operations on some of Scheme's non-numeric data types:
4732booleans, 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
4739The standard boolean objects for true and false are written as
4740@t{#t} and @t{#f}. What really
4741@vindex #f
4742@vindex #t
4743matters, though, are the objects that the Scheme conditional expressions
4744(@samp{if}, @samp{cond}, @samp{and}, @samp{or}, @samp{do}) treat as
4745true 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
4749conditional 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
4753Of all the standard Scheme values, only @t{#f}
4754@c is guaranteed to count
4755counts 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.
4759Except for @t{#f},
4760@c and possibly the empty list,
4761all standard Scheme values, including @t{#t},
4762pairs, the empty list, symbols, numbers, strings, vectors, and procedures,
4763count 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:}
4781Programmers accustomed to other dialects of Lisp should be aware that
4782Scheme distinguishes both @t{#f} and the empty list
4783@cindex @w{empty list}
4784from the symbol @code{nil}.
4785@vindex @w{nil}
4786@end quotation
4787
4788
4789Boolean constants evaluate to themselves, so they do not need to be quoted
4790in 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
4848A @dfn{pair} (sometimes called a @dfn{dotted pair}) is a
4849@cindex @w{dotted pair}
4850@cindex @w{pair}
4851record structure with two fields called the car and cdr fields (for
4852historical reasons). Pairs are created by the procedure @samp{cons}.
4853The 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
4857Pairs are used primarily to represent lists. A list can
4858be defined recursively as either the empty list or a pair whose
4859@cindex @w{empty list}
4860cdr is a list. More precisely, the set of lists is defined as the smallest
4861set @var{X} such that
4862
4863
4864
4865@itemize @bullet
4866
4867@item
4868The empty list is in @var{X}.
4869@item
4870If @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
4876The objects in the car fields of successive pairs of a list are the
4877elements of the list. For example, a two-element list is a pair whose car
4878is the first element and whose cdr is a pair whose car is the second element
4879and whose cdr is the empty list. The length of a list is the number of
4880elements, which is the same as the number of pairs.
4881
4882The 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:}
4889The above definitions imply that all lists have finite length and are
4890terminated by the empty list.
4891@end quotation
4892
4893
4894The most general notation (external representation) for Scheme pairs is
4895the ``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
4897cdr field. For example @samp{(4 .@: 5)} is a pair whose car is 4 and whose
4898cdr is 5. Note that @samp{(4 .@: 5)} is the external representation of a
4899pair, not an expression that evaluates to a pair.
4900
4901A more streamlined notation can be used for lists: the elements of the
4902list are simply enclosed in parentheses and separated by spaces. The
4903empty 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
4914and
4915
4916
4917@example
4918
4919(a . (b . (c . (d . (e . ())))))
4920
4921@end example
4922
4923
4924are equivalent notations for a list of symbols.
4925
4926A 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}
4929The list and dotted notations can be combined to represent
4930improper lists:
4931
4932
4933@example
4934
4935(a b c . d)
4936
4937@end example
4938
4939
4940is equivalent to
4941
4942
4943@example
4944
4945(a . (b . (c . d)))
4946
4947@end example
4948
4949
4950Whether a given pair is a list depends upon what is stored in the cdr
4951field. When the @code{set-cdr!} procedure is used, an object can be a
4952@vindex @w{set-cdr!}
4953list one moment and not the next:
4954
4955
4956@example
4957
4958(define x (list 'a 'b 'c))
4959(define y x)
4960y ==> (a b c)
4961(list? y) ==> #t
4962(set-cdr! x 4) ==> @emph{unspecified}
4963x ==> (a . 4)
4964(eqv? x y) ==> #t
4965y ==> (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
4987Within 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
4994the 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}
5000is @r{<datum>}. This convention is supported so that arbitrary Scheme
5001programs may be represented as lists.
5002@ignore todo
5003Can or need this be stated
5004more carefully?
5005@end ignore
5006 That is, according to Scheme's grammar, every
5007<expression> is also a <datum> (see section @pxref{External representation}).
5008Among other things, this permits the use of the @samp{read} procedure to
5009parse 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
5016returns @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
5033Returns 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
5057Returns the contents of the car field of @var{pair}. Note that it is an
5058error 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
5081Returns the contents of the cdr field of @var{pair}.
5082Note 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
5103Stores @var{obj} in the car field of @var{pair}.
5104The 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
5128Stores @var{obj} in the cdr field of @var{pair}.
5129The 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
5148These procedures are compositions of @samp{car} and @samp{cdr}, where
5149for 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
5158Arbitrary compositions, up to four deep, are provided. There are
5159twenty-eight of these procedures in all.
5160
5161@end deffn
5162
5163
5164
5165@deffn {library procedure} null? obj
5166
5167Returns @t{#t} if @var{obj} is the empty list,
5168@cindex @w{empty list}
5169otherwise 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
5182Returns @t{#t} if @var{obj} is a list, otherwise returns @t{#f}.
5183By definition, all lists have finite length and are terminated by
5184the 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
5203Returns 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
5222Returns 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
5239All @var{list}s should be lists.
5240@end ignore
5241
5242Returns a list consisting of the elements of the first @var{list}
5243followed 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
5254The resulting list is always newly allocated, except that it shares
5255structure with the last @var{list} argument. The last argument may
5256actually be any object; an improper list results if the last argument is not a
5257proper list.
5258@ignore todo
5259This 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
5280Returns a newly allocated list consisting of the elements of @var{list}
5281in 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
5297Returns the sublist of @var{list} obtained by omitting the first @var{k}
5298elements. 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
5317Returns the @var{k}th element of @var{list}. (This is the same
5318as the car of @t{(list-tail @var{list} @var{k})}.)
5319It 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
5355These 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
5357returned by @t{(list-tail @var{list} @var{k})} for @var{k} less
5358than the length of @var{list}. If
5359@var{obj} does not occur in @var{list}, then @t{#f} (not the empty list) is
5360returned. @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
5386pairs. These procedures find the first pair in @var{alist} whose car field is @var{obj},
5387and returns that pair. If no pair in @var{alist} has @var{obj} as its
5388car, 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},
5390while @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:}
5414Although they are ordinarily used as predicates,
5415@samp{memq}, @samp{memv}, @samp{member}, @samp{assq}, @samp{assv}, and @samp{assoc} do not
5416have question marks in their names because they return useful values rather
5417than 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
5428Symbols are objects whose usefulness rests on the fact that two
5429symbols are identical (in the sense of @samp{eqv?}) if and only if their
5430names are spelled the same way. This is exactly the property needed to
5431represent identifiers in programs, and so most
5432@cindex @w{identifier}
5433implementations of Scheme use them internally for that purpose. Symbols
5434are useful for many other applications; for instance, they may be used
5435the way enumerated values are used in Pascal.
5436
5437The rules for writing a symbol are exactly the same as the rules for
5438writing an identifier; see sections @ref{Identifiers}
5439and @ref{Lexical structure}.
5440
5441It is guaranteed that any symbol that has been returned as part of
5442a literal expression, or read using the @samp{read} procedure, and
5443subsequently written out using the @samp{write} procedure, will read back
5444in as the identical symbol (in the sense of @samp{eqv?}). The
5445@samp{string->symbol} procedure, however, can create symbols for
5446which this write/read invariance may not hold because their names
5447contain special characters or letters in the non-standard case.
5448
5449
5450@quotation
5451@emph{Note:}
5452Some implementations of Scheme have a feature known as ``slashification''
5453in order to guarantee write/read invariance for all symbols, but
5454historically the most important use of this feature has been to
5455compensate for the lack of a string data type.
5456
5457Some implementations also have ``uninterned symbols'', which
5458defeat write/read invariance even in implementations with slashification,
5459and also generate exceptions to the rule that two symbols are the same
5460if and only if their names are spelled the same.
5461@end quotation
5462
5463
5464
5465
5466@deffn {procedure} symbol? obj
5467
5468Returns @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
5487Returns the name of @var{symbol} as a string. If the symbol was part of
5488an object returned as the value of a literal expression
5489(section @pxref{Literal expressions}) or by a call to the @samp{read} procedure,
5490and its name contains alphabetic characters, then the string returned
5491will contain characters in the implementation's preferred standard
5492case---some implementations will prefer upper case, others lower case.
5493If the symbol was returned by @samp{string->symbol}, the case of
5494characters in the string returned will be the same as the case in the
5495string that was passed to @samp{string->symbol}. It is an error
5496to apply mutation procedures like @code{string-set!} to strings returned
5497@vindex @w{string-set!}
5498by this procedure.
5499
5500The following examples assume that the implementation's standard case is
5501lower 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
5520Returns the symbol whose name is @var{string}. This procedure can
5521create symbols with names containing special characters or letters in
5522the non-standard case, but it is usually a bad idea to create such
5523symbols because in some implementations of Scheme they cannot be read as
5524themselves. See @samp{symbol->string}.
5525
5526The following examples assume that the implementation's standard case is
5527lower 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
5558Characters are objects that represent printed characters such as
5559letters 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.
5564Characters are written using the notation #\@r{<character>}
5565or #\@r{<character name>}.
5566For 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
5592Case is significant in #\@r{<character>}, but not in
5593#\@r{<character name>}.
5594@c \hyper doesn't
5595
5596@c allow a linebreak
5597If @r{<character>} in
5598#\@r{<character>} is alphabetic, then the character
5599following @r{<character>} must be a delimiter character such as a
5600space or parenthesis. This rule resolves the ambiguous case where, for
5601example, the sequence of characters ``@t{#\ space}''
5602could be taken to be either a representation of the space character or a
5603representation of the character ``@t{#\ s}'' followed
5604by a representation of the symbol ``@t{pace}.''
5605
5606@ignore todo
5607Fix
5608@end ignore
5609
5610Characters written in the #\ notation are self-evaluating.
5611That 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
5617Some of the procedures that operate on characters ignore the
5618difference between upper case and lower case. The procedures that
5619ignore case have @w{``@t{-ci}''} (for ``case
5620insensitive'') embedded in their names.
5621
5622
5623
5624@deffn {procedure} char? obj
5625
5626Returns @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
5640Both @var{char1} and @var{char2} must be characters.
5641@end ignore
5642
5643These procedures impose a total ordering on the set of characters. It
5644is guaranteed that under this ordering:
5645
5646
5647
5648@itemize @bullet
5649
5650@item
5651The upper case characters are in order. For example, @samp{(char<? #\A #\B)} returns @t{#t}.
5652@item
5653The lower case characters are in order. For example, @samp{(char<? #\a #\b)} returns @t{#t}.
5654@item
5655The digits are in order. For example, @samp{(char<? #\0 #\9)} returns @t{#t}.
5656@item
5657Either all the digits precede all the upper case letters, or vice versa.
5658@item
5659Either all the digits precede all the lower case letters, or vice versa.
5660
5661@end itemize
5662
5663
5664Some implementations may generalize these procedures to take more than
5665two 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
5678Both @var{char1} and @var{char2} must be characters.
5679@end ignore
5680
5681These procedures are similar to @samp{char=?} et cetera, but they treat
5682upper case and lower case letters as the same. For example, @samp{(char-ci=? #\A #\a)} returns @t{#t}. Some
5683implementations may generalize these procedures to take more than two
5684arguments, 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
5696These procedures return @t{#t} if their arguments are alphabetic,
5697numeric, whitespace, upper case, or lower case characters, respectively,
5698otherwise they return @t{#f}. The following remarks, which are specific to
5699the ASCII character set, are intended only as a guide: The alphabetic characters
5700are the 52 upper and lower case letters. The numeric characters are the
5701ten decimal digits. The whitespace characters are space, tab, line
5702feed, 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
5720Given a character, @samp{char->integer} returns an exact integer
5721representation of the character. Given an exact integer that is the image of
5722a character under @samp{char->integer}, @samp{integer->char}
5723returns that character. These procedures implement order-preserving isomorphisms
5724between the set of characters under the @code{char<=?} ordering and some
5725@vindex @w{char<=?}
5726subset 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
5762These procedures return a character @var{char2} such that @samp{(char-ci=? @var{char} @var{char2})}. In addition, if @var{char} is
5763alphabetic, then the result of @samp{char-upcase} is upper case and the
5764result 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
5774Strings 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.
5778Strings are written as sequences of characters enclosed within doublequotes
5779(@samp{"}). A doublequote can be written inside a string only by escaping
5780it with a backslash (\), as in
5781
5782
5783@example
5784
5785"The word \"recursion\" has many meanings."
5786
5787@end example
5788
5789
5790A backslash can be written inside a string only by escaping it with another
5791backslash. Scheme does not specify the effect of a backslash within a
5792string that is not followed by a doublequote or backslash.
5793
5794A string constant may continue from one line to the next, but
5795the 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
5801The @emph{length} of a string is the number of characters that it
5802contains. This number is an exact, non-negative integer that is fixed when the
5803string is created. The @dfn{valid indexes} of a string are the
5804@cindex @w{valid indexes}
5805exact non-negative integers less than the length of the string. The first
5806character of a string has index 0, the second has index 1, and so on.
5807
5808In phrases such as ``the characters of @var{string} beginning with
5809index @var{start} and ending with index @var{end},'' it is understood
5810that the index @var{start} is inclusive and the index @var{end} is
5811exclusive. Thus if @var{start} and @var{end} are the same index, a null
5812substring is referred to, and if @var{start} is zero and @var{end} is
5813the length of @var{string}, then the entire string is referred to.
5814
5815Some of the procedures that operate on strings ignore the
5816difference between upper and lower case. The versions that ignore case
5817have @w{``@samp{-ci}''} (for ``case insensitive'') embedded in their
5818names.
5819
5820
5821
5822@deffn {procedure} string? obj
5823
5824Returns @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
5835length @var{k}. If @var{char} is given, then all elements of the string
5836are 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
5844Returns a newly allocated string composed of the arguments.
5845
5846@end deffn
5847
5848
5849@deffn {procedure} string-length string
5850
5851Returns 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}
5872and 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
5895Returns @t{#t} if the two strings are the same length and contain the same
5896characters in the same positions, otherwise returns @t{#f}.
5897@samp{String-ci=?} treats
5898upper 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
5914These procedures are the lexicographic extensions to strings of the
5915corresponding orderings on characters. For example, @samp{string<?} is
5916the lexicographic ordering on strings induced by the ordering
5917@samp{char<?} on characters. If two strings differ in length but
5918are the same up to the length of the shorter string, the shorter string
5919is considered to be lexicographically less than the longer string.
5920
5921Implementations may generalize these and the @samp{string=?} and
5922@samp{string-ci=?} procedures to take more than two arguments, as with
5923the 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}
5932must 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
5946Returns a newly allocated string whose characters form the concatenation of the
5947given 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
5957characters that make up the given string. @samp{List->string}
5958returns a newly allocated string formed from the characters in the list
5959@var{list}, which must be a list of characters. @samp{String->list}
5960and @samp{list->string} are
5961inverses 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
5972Returns 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
5980Stores @var{char} in every element of the given @var{string} and returns an
5981unspecified value.
5982@c <!>
5983
5984@end deffn
5985
5986
5987@node Vectors, , Strings, Other data types
5988@subsection Vectors
5989
5990
5991
5992Vectors are heterogenous structures whose elements are indexed
5993by integers. A vector typically occupies less space than a list
5994of the same length, and the average time required to access a randomly
5995chosen element is typically less for the vector than for the list.
5996
5997The @emph{length} of a vector is the number of elements that it
5998contains. This number is a non-negative integer that is fixed when the
5999vector is created. The @emph{valid indexes} of a
6000@cindex @w{valid indexes}
6001vector are the exact non-negative integers less than the length of the
6002vector. The first element in a vector is indexed by zero, and the last
6003element is indexed by one less than the length of the vector.
6004
6005Vectors are written using the notation @t{#(@var{obj} @dots{},)}.
6006For example, a vector of length 3 containing the number zero in element
60070, the list @samp{(2 2 2 2)} in element 1, and the string @samp{"Anna"} in
6008element 2 can be written as following:
6009
6010
6011@example
6012
6013#(0 (2 2 2 2) "Anna")
6014
6015@end example
6016
6017
6018Note that this is the external representation of a vector, not an
6019expression evaluating to a vector. Like list constants, vector
6020constants 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
6032Pitman sez: The visual similarity to lists is bound to be confusing
6033to some. Elaborate on the distinction.
6034@end ignore
6035
6036
6037
6038
6039@deffn {procedure} vector? obj
6040
6041Returns @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
6049Returns a newly allocated vector of @var{k} elements. If a second
6050argument is given, then each element is initialized to @var{fill}.
6051Otherwise the initial contents of each element is unspecified.
6052
6053@end deffn
6054
6055
6056
6057@deffn {library procedure} vector obj @dots{},
6058
6059Returns a newly allocated vector whose elements contain the given
6060arguments. 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
6074Returns 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}.
6107The 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
6130in the elements of @var{vector}. @samp{List->vector} returns a newly
6131created 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
6148Stores @var{fill} in every element of @var{vector}.
6149The 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
6163This chapter describes various primitive procedures which control the
6164flow of program execution in special ways.
6165The @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
6176Returns @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.
6199Calls @var{proc} with the elements of the list
6200@samp{(append (list @var{arg1} @dots{},) @var{args})} as the actual
6201arguments.
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
6222The @var{list}s must be lists, and @var{proc} must be a
6223procedure taking as many arguments as there are @i{list}s
6224and returning a single value. If more
6225than 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.
6228The 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
6257The 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
6259values. Unlike @samp{map}, @samp{for-each} is guaranteed to call @var{proc} on
6260the elements of the @var{list}s in order from the first element(s) to the
6261last, 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
6280Forces the value of @var{promise} (see @code{delay},
6281@vindex @w{delay}
6282section @pxref{Delayed evaluation}). If no value has been computed for
6283@cindex @w{promise}
6284the promise, then a value is computed and returned. The value of the
6285promise is cached (or ``memoized'') so that if it is forced a second
6286time, 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
6314functional style. The following examples should not be considered to
6315illustrate good programming style, but they illustrate the property that
6316only one value is computed for a promise, no matter how many times it is
6317forced.
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)
6332p ==> @i{}a promise
6333(force p) ==> 6
6334p ==> @i{}a promise, still
6335(begin (set! x 10)
6336 (force p)) ==> 6
6337}
6338@end format
6339
6340
6341Here is a possible implementation of @samp{delay} and @samp{force}.
6342Promises are implemented here as procedures of no arguments,
6343and @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
6354We define the expression
6355
6356
6357@format
6358@t{(delay @r{<expression>})
6359}
6360@end format
6361
6362
6363to 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
6372as 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
6384where @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:}
6419A promise may refer to its own value, as in the last example above.
6420Forcing such a promise may cause the promise to be forced a second time
6421before the value of the first force has been computed.
6422This complicates the definition of @samp{make-promise}.
6423@end quotation
6424
6425
6426Various extensions to this semantics of @samp{delay} and @samp{force}
6427are supported in some implementations:
6428
6429
6430
6431@itemize @bullet
6432
6433@item
6434Calling @samp{force} on an object that is not a promise may simply
6435return the object.
6436
6437@item
6438It may be the case that there is no means by which a promise can be
6439operationally distinguished from its forced value. That is, expressions
6440like the following may evaluate to either @t{#t} or to @t{#f},
6441depending 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
6452Some implementations may implement ``implicit forcing,'' where
6453the value of a promise is forced by primitive procedures like @samp{cdr}
6454and @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
6471argument. The procedure @samp{call-with-current-continuation} packages
6472up the current continuation (see the rationale below) as an ``escape
6473procedure'' 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
6476later called, will abandon whatever continuation is in effect at that later
6477time and will instead use the continuation that was in effect
6478when the escape procedure was created. Calling the escape procedure
6479may cause the invocation of @var{before} and @var{after} thunks installed using
6480@code{dynamic-wind}.
6481@vindex @w{dynamic-wind}
6482
6483The escape procedure accepts the same number of arguments as the continuation to
6484the original call to @t{call-with-current-continuation}.
6485Except for continuations created by the @samp{call-with-values}
6486procedure, all continuations take exactly one value. The
6487effect of passing no value or more than one value to continuations
6488that were not created by @t{call-with-values} is unspecified.
6489
6490The escape procedure that is passed to @var{proc} has
6491unlimited extent just like any other procedure in Scheme. It may be stored
6492in variables or data structures and may be called as many times as desired.
6493
6494The following examples show only the most common ways in which
6495@samp{call-with-current-continuation} is used. If all real uses were as
6496simple as these examples, there would be no need for a procedure with
6497the 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
6532A common use of @samp{call-with-current-continuation} is for
6533structured, non-local exits from loops or procedure bodies, but in fact
6534@samp{call-with-current-continuation} is extremely useful for implementing a
6535wide variety of advanced control structures.
6536
6537Whenever a Scheme expression is evaluated there is a
6538@dfn{continuation} wanting the result of the expression. The continuation
6539@cindex @w{continuation}
6540represents an entire (default) future for the computation. If the expression is
6541evaluated at top level, for example, then the continuation might take the
6542result, print it on the screen, prompt for the next input, evaluate it, and
6543so on forever. Most of the time the continuation includes actions
6544specified by user code, as in a continuation that will take the result,
6545multiply it by the value stored in a local variable, add seven, and give
6546the answer to the top level continuation to be printed. Normally these
6547ubiquitous continuations are hidden behind the scenes and programmers do not
6548think much about them. On rare occasions, however, a programmer may
6549need to deal with continuations explicitly.
6550@samp{Call-with-current-continuation} allows Scheme programmers to do
6551that by creating a procedure that acts just like the current
6552continuation.
6553
6554Most programming languages incorporate one or more special-purpose
6555escape constructs with names like @t{exit}, @w{@samp{return}}, or
6556even @t{goto}. In 1965, however, Peter Landin [Landin65]
6557invented a general purpose escape operator called the J-operator. John
6558Reynolds [Reynolds72] described a simpler but equally powerful
6559construct in 1972. The @samp{catch} special form described by Sussman
6560and Steele in the 1975 report on Scheme is exactly the same as
6561Reynolds's construct, though its name came from a less general construct
6562in 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}
6565special syntactic construct, and the name
6566@samp{call-with-current-continuation} was coined in 1982. This name is
6567descriptive, but opinions differ on the merits of such a long name, and
6568some 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
6578Delivers all of its arguments to its continuation.
6579Except for continuations created by the @code{call-with-values}
6580@vindex @w{call-with-values}
6581procedure, 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
6597Calls its @var{producer} argument with no values and
6598a continuation that, when passed some values, calls the
6599@var{consumer} procedure with those values as arguments.
6600The continuation for the call to @var{consumer} is the
6601continuation 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
6619Calls @var{thunk} without arguments, returning the result(s) of this call.
6620@var{Before} and @var{after} are called, also without arguments, as required
6621by the following rules (note that in the absence of calls to continuations
6622captured using @code{call-with-current-continuation} the three arguments are
6623@vindex @w{call-with-current-continuation}
6624called once each, in order). @var{Before} is called whenever execution
6625enters the dynamic extent of the call to @var{thunk} and @var{after} is called
6626whenever it exits that dynamic extent. The dynamic extent of a procedure
6627call is the period between when the call is initiated and when it
6628returns. In Scheme, because of @samp{call-with-current-continuation}, the
6629dynamic extent of a call may not be a single, connected time period.
6630It is defined as follows:
6631
6632
6633@itemize @bullet
6634
6635@item
6636The dynamic extent is entered when execution of the body of the
6637called procedure begins.
6638
6639@item
6640The dynamic extent is also entered when execution is not within
6641the dynamic extent and a continuation is invoked that was captured
6642(using @samp{call-with-current-continuation}) during the dynamic extent.
6643
6644@item
6645It is exited when the called procedure returns.
6646
6647@item
6648It is also exited when execution is within the dynamic extent and
6649a continuation is invoked that was captured while not within the
6650dynamic extent.
6651
6652@end itemize
6653
6654
6655If a second call to @samp{dynamic-wind} occurs within the dynamic extent of the
6656call 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
6658called, then the @var{after} associated with the second (inner) call to
6659@samp{dynamic-wind} is called first.
6660
6661If a second call to @samp{dynamic-wind} occurs within the dynamic extent of the
6662call 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
6664called, then the @var{before} associated with the first (outer) call to
6665@samp{dynamic-wind} is called first.
6666
6667If invoking a continuation requires calling the @var{before} from one call
6668to @samp{dynamic-wind} and the @var{after} from another, then the @var{after}
6669is called first.
6670
6671The effect of using a captured continuation to enter or exit the dynamic
6672extent 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
6706Evaluates @var{expression} in the specified environment and returns its value.
6707@var{Expression} must be a valid Scheme expression represented as data,
6708and @var{environment-specifier} must be a value returned by one of the
6709three procedures described below.
6710Implementations may extend @samp{eval} to allow non-expression programs
6711(definitions) as the first argument and to allow other
6712values as environments, with the restriction that @samp{eval} is not
6713allowed 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},
6736corresponding to this revision of the Scheme report (the
6737Revised^5 Report on Scheme).
6738@samp{Scheme-report-environment} returns a specifier for an
6739environment that is empty except for all bindings defined in
6740this report that are either required or both optional and
6741supported by the implementation. @samp{Null-environment} returns
6742a specifier for an environment that is empty except for the
6743(syntactic) bindings for all syntactic keywords defined in
6744this report that are either required or both optional and
6745supported by the implementation.
6746
6747Other values of @var{version} can be used to specify environments
6748matching past revisions of this report, but their support is not
6749required. An implementation will signal an error if @var{version}
6750is neither @samp{5} nor another value supported by
6751the implementation.
6752
6753The effect of assigning (through the use of @samp{eval}) a variable
6754bound in a @samp{scheme-report-environment}
6755(for example @samp{car}) is unspecified. Thus the environments specified
6756by @samp{scheme-report-environment} may be immutable.
6757
6758@end deffn
6759
6760
6761@deffn {optional procedure} interaction-environment
6762
6763This procedure returns a specifier for the environment that
6764contains imple@-men@-ta@-tion-defined bindings, typically a superset of
6765those listed in the report. The intent is that this procedure
6766will return the environment in which the implementation would evaluate
6767expressions 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
6787Ports represent input and output devices. To Scheme, an input port is a
6788Scheme object that can deliver characters upon command, while an output port
6789is a Scheme object that can accept characters.
6790@cindex @w{port}
6791
6792@ignore todo
6793Haase: 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.
6803For @samp{call-with-input-file},
6804the file should already exist; for
6805@samp{call-with-output-file},
6806the effect is unspecified if the file
6807already exists. These procedures call @var{proc} with one argument: the
6808port obtained by opening the named file for input or output. If the
6809file cannot be opened, an error is signalled. If @var{proc} returns,
6810then 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
6812the port will not be closed automatically unless it is possible to
6813prove that the port will never again be used for a read or write
6814operation.
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:}
6822Because Scheme's escape procedures have unlimited extent, it is
6823possible to escape from the current continuation but later to escape back in.
6824If implementations were permitted to close the port on any escape from the
6825current continuation, then it would be impossible to write portable code using
6826both @samp{call-with-current-continuation} and @samp{call-with-input-file} or
6827@samp{call-with-output-file}.
6828@ignore todo
6829Pitman 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
6842Returns @t{#t} if @var{obj} is an input port or output port
6843respectively, otherwise returns @t{#f}.
6844
6845@ignore todo
6846Won'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
6857Returns 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.
6868For @samp{with-input-from-file},
6869the file should already exist; for
6870@samp{with-output-to-file},
6871the effect is unspecified if the file
6872already exists.
6873The file is opened for input or output, an input or output port
6874connected 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),
6877and the
6878@var{thunk} is called with no arguments. When the @var{thunk} returns,
6879the port is closed and the previous default is restored.
6880@samp{With-input-from-file} and @samp{with-output-to-file} return(s) the
6881value(s) yielded by @var{thunk}.
6882If an escape procedure
6883is used to escape from the continuation of these procedures, their
6884behavior is implementation dependent.
6885
6886@ignore todo
6887OK 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
6894Freeman:
6895Throughout this section I wanted to see ``the value of @t{(current-input-port)}''
6896instead 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
6908Takes a string naming an existing file and returns an input port capable of
6909delivering characters from the file. If the file cannot be opened, an error is
6910signalled.
6911
6912@end deffn
6913
6914
6915
6916@deffn {procedure} open-output-file filename
6917
6918Takes a string naming an output file to be created and returns an output
6919port capable of writing characters to a new file by that name. If the file
6920cannot be opened, an error is signalled. If a file with the given name
6921already 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
6930Closes the file associated with @var{port}, rendering the @var{port}
6931incapable of delivering or accepting characters.
6932@ignore todo
6933But maybe a no-op
6934on some ports, e.g. terminals or editor buffers.
6935@end ignore
6936
6937These routines have no effect if the file has already been closed.
6938The value returned is unspecified.
6939
6940@ignore todo
6941Ramsdell: Some note is needed explaining why there are two
6942different close procedures.
6943@end ignore
6944
6945
6946@ignore todo
6947A 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
6965The 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
6974objects 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
6977object parsable from the given input @var{port}, updating @var{port} to point to
6978the first character past the end of the external representation of the object.
6979
6980If an end of file is encountered in the input before any
6981characters are found that can begin an object, then an end of file
6982object is returned.
6983@ignore todo
6984
6985@end ignore
6986 The port remains open, and further attempts
6987to read will also return an end of file object. If an end of file is
6988encountered after the beginning of an object's external representation,
6989but the external representation is incomplete and therefore not parsable,
6990an error is signalled.
6991
6992The @var{port} argument may be omitted, in which case it defaults to the
6993value returned by @samp{current-input-port}. It is an error to read from
6994a closed port.
6995@end deffn
6996
6997
6998@deffn {procedure} read-char
6999@deffnx {procedure} read-char port
7000
7001Returns the next character available from the input @var{port}, updating
7002the @var{port} to point to the following character. If no more characters
7003are available, an end of file object is returned. @var{Port} may be
7004omitted, 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
7013Returns the next character available from the input @var{port},
7014@emph{without} updating
7015the @var{port} to point to the following character. If no more characters
7016are available, an end of file object is returned. @var{Port} may be
7017omitted, in which case it defaults to the value returned by @samp{current-input-port}.
7018
7019
7020@quotation
7021@emph{Note:}
7022The value returned by a call to @samp{peek-char} is the same as the
7023value that would have been returned by a call to @samp{read-char} with the
7024same @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
7026value returned by the preceding call to @samp{peek-char}. In particular, a call
7027to @samp{peek-char} on an interactive port will hang waiting for input
7028whenever 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
7038Returns @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
7040implementations, but in any case no end of file object will ever be an object
7041that 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
7050Returns @t{#t} if a character is ready on the input @var{port} and
7051returns @t{#f} otherwise. If @samp{char-ready} returns @t{#t} then
7052the next @samp{read-char} operation on the given @var{port} is guaranteed
7053not to hang. If the @var{port} is at end of file then @samp{char-ready?}
7054returns @t{#t}. @var{Port} may be omitted, in which case it defaults to
7055the 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
7061accept characters from interactive ports without getting stuck waiting for
7062input. Any input editors associated with such ports must ensure that
7063characters whose existence has been asserted by @samp{char-ready?} cannot
7064be rubbed out. If @samp{char-ready?} were to return @t{#f} at end of
7065file, a port at end of file would be indistinguishable from an interactive
7066port 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
7087Writes a written representation of @var{obj} to the given @var{port}. Strings
7088that appear in the written representation are enclosed in doublequotes, and
7089within those strings backslash and doublequote characters are
7090escaped by backslashes.
7091Character 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
7094returned 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
7103Writes a representation of @var{obj} to the given @var{port}. Strings
7104that appear in the written representation are not enclosed in
7105doublequotes, and no characters are escaped within those strings. Character
7106objects appear in the representation as if written by @samp{write-char}
7107instead of by @samp{write}. @samp{Display} returns an unspecified value.
7108The @var{port} argument may be omitted, in which case it defaults to the
7109value returned by @samp{current-output-port}.
7110
7111
7112@quotation
7113@emph{Rationale:}
7114@samp{Write} is intended
7115for producing mach@-ine-readable output and @samp{display} is for producing
7116human-readable output. Implementations that allow ``slashification''
7117within symbols will probably want @samp{write} but not @samp{display} to
7118slashify 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
7128Writes an end of line to @var{port}. Exactly how this is done differs
7129from one operating system to another. Returns an unspecified value.
7130The @var{port} argument may be omitted, in which case it defaults to the
7131value 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
7140Writes the character @var{char} (not an external representation of the
7141character) 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
7143returned 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
7152Questions of system interface generally fall outside of the domain of this
7153report. However, the following operations are important enough to
7154deserve description here.
7155
7156
7157
7158@deffn {optional procedure} load filename
7159
7160@ignore todo
7161Fix
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
7168containing Scheme source code. The @samp{load} procedure reads
7169expressions and definitions from the file and evaluates them
7170sequentially. It is unspecified whether the results of the expressions
7171are printed. The @samp{load} procedure does not affect the values
7172returned by @samp{current-input-port} and @samp{current-output-port}.
7173@samp{Load} returns an unspecified value.
7174
7175
7176@quotation
7177@emph{Rationale:}
7178For portability, @samp{load} must operate on source files.
7179Its operation on other kinds of files necessarily varies among
7180implementations.
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
7191created. The effect of @samp{transcript-on} is to open the named file
7192for output, and to cause a transcript of subsequent interaction between
7193the user and the Scheme system to be written to the file. The
7194transcript is ended by a call to @samp{transcript-off}, which closes the
7195transcript file. Only one transcript may be in progress at any time,
7196though some implementations may relax this restriction. The values
7197returned 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
7219This chapter provides formal descriptions of what has already been
7220described informally in previous chapters of this report.
7221
7222@ignore todo
7223Allow 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
7242This section provides a formal syntax for Scheme written in an extended
7243BNF.
7244
7245All spaces in the grammar are for legibility. Case is insignificant;
7246for example, @samp{#x1A} and @samp{#X1a} are equivalent. <empty>
7247stands for the empty string.
7248
7249The following extensions to BNF are used to make the description more
7250concise: <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
7259This section describes how individual tokens (identifiers,
7260@cindex @w{token}
7261numbers, etc.) are formed from sequences of characters. The following
7262sections describe how expressions and programs are formed from sequences
7263of tokens.
7264
7265<Intertoken space> may occur on either side of any token, but not
7266within a token.
7267
7268Tokens which require implicit termination (identifiers, numbers,
7269characters, and dot) may be terminated by any <delimiter>, but not
7270necessarily by anything else.
7271
7272The following five characters are reserved for future extensions to the
7273language: @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
7353The following rules for <num R>, <complex R>, <real
7354R>, <ureal R>, <uinteger R>, and <prefix R>
7355should be replicated for @w{R = 2, 8, 10,}
7356and 16. There are no rules for <decimal 2>, <decimal
73578>, and <decimal 16>, which means that numbers containing
7358decimal points or exponents must be in decimal radix.
7359@ignore todo
7360Mark 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
7414Mark 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}
7426successfully 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
7536The following grammar for quasiquote expressions is not context-free.
7537It is presented as a recipe for generating an infinite number of
7538production 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
7566In <quasiquotation>s, a <list qq template D> can sometimes
7567be confused with either an <un@-quota@-tion D> or a <splicing
7568un@-quo@-ta@-tion D>. The interpretation as an
7569<un@-quo@-ta@-tion> or <splicing
7570un@-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
7636This section provides a formal denotational semantics for the primitive
7637expressions of Scheme and selected built-in procedures. The concepts
7638and notation used here are described in @sc{[Stoy77]}.
7639
7640@quotation
7641@emph{Note:} The formal semantics section was written in La@TeX{} which
7642is incompatible with @TeX{}info. See the Formal semantics section of
7643the 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
7653This section gives macro definitions for the derived expression types in
7654terms of the primitive expression types (literal, variable, call, @samp{lambda},
7655@samp{if}, @samp{set!}). See section @ref{Control features} for a possible
7656definition 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
7776The following @samp{letrec} macro uses the symbol @samp{<undefined>}
7777in place of an expression which returns something that when stored in
7778a location makes it an error to try to obtain the value stored in the
7779location (no such expression is defined in Scheme).
7780A trick is used to generate the temporary names needed to avoid
7781specifying the order in which the values are evaluated.
7782This 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
7830The following alternative expansion for @samp{begin} does not make use of
7831the ability to write more than one expression in the body of a lambda
7832expression. In any case, note that these rules apply only if the body
7833of 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
7849The following definition
7850of @samp{do} uses a trick to expand the variable clauses.
7851As with @samp{letrec} above, an auxiliary macro would also work.
7852The expression @samp{(if #f #f)} is used to obtain an unspecific
7853value.
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
7908Perhaps this section should be made to disappear.
7909Can these remarks be moved somewhere else?
7910@end ignore
7911
7912
7913@node Language changes, , Notes, Notes
7914@unnumberedsec Language changes
7915
7916
7917
7918This section enumerates the changes that have been made to Scheme since
7919the ``Revised^4 report'' [R4RS] was published.
7920
7921
7922
7923@itemize @bullet
7924
7925
7926@item
7927The report is now a superset of the IEEE standard for Scheme
7928[IEEEScheme]: implementations that conform to the report will
7929also conform to the standard. This required the following changes:
7930
7931
7932@itemize @bullet
7933
7934
7935@item
7936The empty list is now required to count as true.
7937
7938@item
7939The classification of features as essential or inessential has been
7940removed. There are now three classes of built-in procedures: primitive,
7941library, 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},
7945and @samp{-} and @samp{/} with more than two arguments.
7946None of these are in the IEEE standard.
7947
7948@item
7949Programs are allowed to redefine built-in procedures. Doing so
7950will 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
7959The macro appendix has been removed. High-level macros are now part
7960of the main body of the report. The rewrite rules for derived expressions
7961have been replaced with macro definitions. There are no reserved identifiers.
7962
7963@item
7964@samp{Syntax-rules} now allows vector patterns.
7965
7966@item
7967Multiple-value returns, @samp{eval}, and @samp{dynamic-wind} have
7968been added.
7969
7970@item
7971The calls that are required to be implemented in a properly tail-recursive
7972fashion are defined explicitly.
7973
7974@item
7975`@samp{@@}' can be used within identifiers. `@samp{|}' is reserved
7976for 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
8036Move cwcc history back here? --- Andy Cromarty is concerned about
8037confusion over who the audience is.
8038@end ignore
8039
8040
8041@ignore todo
8042Cromarty:
804323. 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
8059The Internet Scheme Repository at
8060
8061@center
8062@center @url{http://www.cs.indiana.edu/scheme-repository/}
8063@center
8064
8065contains an extensive Scheme bibliography, as well as papers,
8066programs, 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
8083of differential equations with the method of Runge-Kutta.
8084
8085The parameter @t{system-derivative} is a function that takes a system
8086state (a vector of values for the state variables y_1, @dots{}, y_n)
8087and produces a system derivative (the values y_1^^, @dots{},y_n^^). The parameter @t{initial-state} provides an initial
8088system state, and @t{h} is an initial guess for the length of the
8089integration step.
8090
8091The value returned by @samp{integrate-system} is an infinite stream of
8092system 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
8110system derivative from a system state. @samp{Runge-Kutta-4}
8111produces a function that takes a system state and
8112produces 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
8168argument (a procedure) to all the elements of its second argument (a
8169stream).
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
8182Infinite streams are implemented as pairs whose car holds the first
8183element of the stream and whose cdr holds a promise to deliver the rest
8184of 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
8197The following illustrates the use of @samp{integrate-system} in
8198integrating 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
8207which 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
8230Show 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
8305Harold Abelson and Gerald Jay Sussman with Julie Sussman.
8306@emph{Structure and Interpretation of Computer Programs, second edition.}
8307MIT Press, Cambridge, 1996.
8308
8309@item [Bawden88]
8310@c new
8311Alan Bawden and Jonathan Rees.
8312@pindex Bawden88
8313Syntactic closures.
8314In @emph{Proceedings of the 1988 ACM Symposium on Lisp and
8315 Functional Programming}, pages 86--95.
8316
8317@item [howtoprint]
8318@pindex howtoprint
8319Robert G. Burger and R. Kent Dybvig.
8320Printing floating-point numbers quickly and accurately.
8321In @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
8326William Clinger, editor.
8327The revised revised report on Scheme, or an uncommon Lisp.
8328MIT Artificial Intelligence Memo 848, August 1985.
8329Also published as Computer Science Department Technical Report 174,
8330 Indiana University, June 1985.
8331
8332@item [howtoread]
8333@c new
8334William Clinger.
8335@pindex howtoread
8336How to read floating point numbers accurately.
8337In @emph{Proceedings of the ACM SIGPLAN '90 Conference
8338 on Programming Language Design and Implementation}, pages 92--101.
8339Proceedings published as @emph{SIGPLAN Notices} 25(6), June 1990.
8340
8341@item [R4RS]
8342@pindex R4RS
8343William Clinger and Jonathan Rees, editors.
8344The revised^4 report on the algorithmic language Scheme.
8345In @emph{ACM Lisp Pointers} 4(3), pages 1--55, 1991.
8346
8347@item [macrosthatwork]
8348@c new
8349William Clinger and Jonathan Rees.
8350@pindex macrosthatwork
8351Macros that work.
8352In @emph{Proceedings of the 1991 ACM Conference on Principles of
8353 Programming Languages}, pages 155--162.
8354
8355@item [propertailrecursion]
8356@c new
8357William Clinger.
8358@pindex propertailrecursion
8359Proper Tail Recursion and Space Efficiency.
8360To 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
8365R. Kent Dybvig, Robert Hieb, and Carl Bruggeman.
8366Syntactic abstraction in Scheme.
8367@emph{Lisp and Symbolic Computation} 5(4):295--326, 1993.
8368
8369@item [Scheme311]
8370@pindex Scheme311
8371Carol Fessenden, William Clinger, Daniel P. Friedman, and Christopher Haynes.
8372Scheme 311 version 4 reference manual.
8373Indiana University Computer Science Technical Report 137, February 1983.
8374Superseded by [Scheme84].
8375
8376@item [Scheme84]
8377@pindex Scheme84
8378D. Friedman, C. Haynes, E. Kohlbecker, and M. Wand.
8379Scheme 84 interim reference manual.
8380Indiana 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
8385Arithmetic.} 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
8394Eugene E. Kohlbecker Jr.
8395@emph{Syntactic Extensions in the Programming Language Lisp.}
8396PhD thesis, Indiana University, August 1986.
8397
8398@item [hygienic]
8399@pindex hygienic
8400Eugene E. Kohlbecker Jr., Daniel P. Friedman, Matthias Felleisen, and Bruce Duba.
8401Hygienic macro expansion.
8402In @emph{Proceedings of the 1986 ACM Conference on Lisp
8403 and Functional Programming}, pages 151--161.
8404
8405@item [Landin65]
8406@pindex Landin65
8407Peter Landin.
8408A 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
8413MIT Department of Electrical Engineering and Computer Science.
8414Scheme manual, seventh edition.
8415September 1984.
8416
8417@item [Naur63]
8418@pindex Naur63
8419Peter Naur et al.
8420Revised 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
8425Paul Penfield, Jr.
8426Principal values and branch cuts in complex APL.
8427In @emph{APL '81 Conference Proceedings,} pages 248--256.
8428ACM SIGAPL, San Francisco, September 1981.
8429Proceedings published as @emph{APL Quote Quad} 12(1), ACM, September 1981.
8430
8431@item [Pitman83]
8432@pindex Pitman83
8433Kent M. Pitman.
8434The revised MacLisp manual (Saturday evening edition).
8435MIT Laboratory for Computer Science Technical Report 295, May 1983.
8436
8437@item [Rees82]
8438@pindex Rees82
8439Jonathan A. Rees and Norman I. Adams IV.
8440T: A dialect of Lisp or, lambda: The ultimate software tool.
8441In @emph{Conference Record of the 1982 ACM Symposium on Lisp and
8442 Functional Programming}, pages 114--122.
8443
8444@item [Rees84]
8445@pindex Rees84
8446Jonathan A. Rees, Norman I. Adams IV, and James R. Meehan.
8447The T manual, fourth edition.
8448Yale University Computer Science Department, January 1984.
8449
8450@item [R3RS]
8451@pindex R3RS
8452Jonathan Rees and William Clinger, editors.
8453The revised^3 report on the algorithmic language Scheme.
8454In @emph{ACM SIGPLAN Notices} 21(12), pages 37--79, December 1986.
8455
8456@item [Reynolds72]
8457@pindex Reynolds72
8458John Reynolds.
8459Definitional interpreters for higher order programming languages.
8460In @emph{ACM Conference Proceedings}, pages 717--740.
8461ACM,
8462@ignore todo
8463month?
8464@end ignore
8465 1972.
8466
8467@item [Scheme78]
8468@pindex Scheme78
8469Guy Lewis Steele Jr. and Gerald Jay Sussman.
8470The revised report on Scheme, a dialect of Lisp.
8471MIT Artificial Intelligence Memo 452, January 1978.
8472
8473@item [Rabbit]
8474@pindex Rabbit
8475Guy Lewis Steele Jr.
8476Rabbit: a compiler for Scheme.
8477MIT Artificial Intelligence Laboratory Technical Report 474, May 1978.
8478
8479@item [CLtL]
8480@pindex CLtL
8481Guy Lewis Steele Jr.
8482@emph{Common Lisp: The Language, second edition.}
8483Digital Press, Burlington MA, 1990.
8484
8485@item [Scheme75]
8486@pindex Scheme75
8487Gerald Jay Sussman and Guy Lewis Steele Jr.
8488Scheme: an interpreter for extended lambda calculus.
8489MIT Artificial Intelligence Memo 349, December 1975.
8490
8491@item [Stoy77]
8492@pindex Stoy77
8493Joseph E. Stoy.
8494@emph{Denotational Semantics: The Scott-Strachey Approach to
8495 Programming Language Theory.}
8496MIT Press, Cambridge, 1977.
8497
8498@item [TImanual85]
8499@pindex TImanual85
8500Texas Instruments, Inc.
8501TI Scheme Language Reference Manual.
8502Preliminary 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
8520The principal entry for each term, procedure, or keyword is listed
8521first, 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