commit 0c0af57d1c074db89ad29d7900050f7abbc3c225
Author: Lassi Kortela
+This document has
+moved to a Wiki.
+
+A draft version of R6RS is now available from
+
+The R6RS editors asked for the following announcements to be included
+here:
+
+We appreciate the response to date from members of the Scheme community.
+
+Status Report in June 2006:
+HTML,
+PDF
+
+Updates in March 2006:
+A Charter for Change (R6RS)
+
+www.r6rs.org
.
+The charter provides for a six-month public comment period.
+The comment period is now open and will continue until March 15, 2007.
+
+
+
+
+
+
+http://www.r6rs.org/r6rs-editors/
.
+http://www.r6rs.org/process.html
.
+
+
+
+
+
+Status Report from March 2005. +
+ ++Amended charter from October 2004, +with a revised progress report +on R6RS. +
+ ++Original charter of January 2004. +
+ + + + diff --git a/www/Documents/Standards/Charter/jan-2004.txt b/www/Documents/Standards/Charter/jan-2004.txt new file mode 100644 index 0000000..8ea19f7 --- /dev/null +++ b/www/Documents/Standards/Charter/jan-2004.txt @@ -0,0 +1,146 @@ + Scheme Standardization + +The following charter and standardization committees have been +approved by the Scheme Strategy Committee. The Strategy Committee was +formed by attendees of the Scheme Workshop in Pittsburgh, October +2002. The draft charter and the committee-selection process were +further confirmed by the attendees of the Scheme Workshop in Boston, +November 2003. + + + Strategy Committee: + Alan Bawden + William Clinger + Kent Dybvig + Matthew Flatt + Richard Kelsey + Manuel Serrano + Michael Sperber + + January 2004 + + +Charter +======= + +Standardization Committees +-------------------------- + + * Steering Committee + + The creation of Scheme standards shall be governed by a Steering + Committee that consists of three members. Its responsibility is to + ensure that the standardization process continues, and to establish + processes by which draft standards are reviewed and accepted by + the Scheme community at large. + + The Steering Committee must replace members who + leave. Replacements must be selected within three months, and the + Steering Committee must announce the replacement to the Scheme + community at large. The Steering Committee itself shall establish + procedures for replacing its members. + + This charter can be amended only by a unanimous vote of the + Steering Committee. + + * Standard Editors + + The creation of Scheme standards documents shall be governed by a + committee of seven Editors, including Editor-in-Chief. The + Editor-in-Chief is responsible for producing standardization + documents. None of the Editors may be a member of the Steering + Committee. + + When the Editors have produced a candidate standard, they present + it to the Steering Committee for review and acceptance. The + Steering Committee shall make no rule concerning the process by + which a candidate standard is produced or revised, but Editors are + encouraged to exploit the Scheme Request for Implementation (SRFI) + process for gathering opinions and suggestions from the Scheme + community at large. + + The Steering Committee must replace Editors who leave. The + replacements must be selected within three months, and the Steering + Committee must announce the replacement to the Scheme community at + large. + + * Scheme Request for Implementation (SRFI) Editors + + The Scheme Request for Implementation process shall remain the + primary vehicle for language design and discussion by the Scheme + community at large. SRFI standards shall be governed by the SRFI + Editors, and shall not be governed or endorsed by the Steering + Committee. Standard Editors are encouraged to draw on the SRFI + process in developing Scheme standards. + + +Recommended Timeline +-------------------- + +The Steering Committee and Editors are ultimately responsible for the +process of Scheme standardization. Nevertheless, as the intent of this +charter is to make timely progress towards a standard, the following +timeline and process suggestions (for a single round of standards) may +serve as a benchmark for the actual process. + + * Drafting + + The Editors should produce a draft standard core Scheme, a draft + module system, and a draft set of initial libraries within 24 + months of the Editors' establishment. + + During these 24 months, the Editors are encouraged to produce short + status reports every 6 months, posted at www.schemers.org. The + Editors are also encouraged to solicit opinions on specific issues + concerning the draft. The Editors are further encouraged to record + electronic discussions and meeting minutes in a publicly readable + archive. + + If the Editors require more than 24 months to complete the draft, + they are encouraged to report this as soon as possible to the + Steering Committee. If the Editors determine they are unable to + produce a draft, they should report this to the Steering Committee + as soon as possible. + + * Review + + When the Editors finish the draft standards, they should provide + the drafts to the Steering Committee, who should in turn publish + the drafts on schemers.org. + + After this, the members of the Steering Committee and the scheme + community at large have 6 months to voice concerns, criticism, and + suggestions for improving the drafts. + + The Editors should attempt to respond to each voiced concern, + detailing a rationale against a concern or indicating the way that + the drafts will change to address a concern. + + The editors are encouraged to publish numbered (or otherwise + identified) intermediate revisions of the report during the review + period, and announce them on schemers.org. + + * Finalization + + After the end of the review period, the Editors should submit new + drafts within three months. The Steering Committee should then + choose either to finalize the drafts or to restart the review + process. + +Current Steering Committee +========================== + + Alan Bawden + Guy L. Steele + Mitchell Wand + +Current Editors +=============== + + Marc Feeley (Editor in Chief) + William D. Clinger + R. Kent Dybvig + Matthew Flatt + Richard Kelsey + Manuel Serrano + Michael Sperber diff --git a/www/Documents/Standards/Charter/mar-2005.txt b/www/Documents/Standards/Charter/mar-2005.txt new file mode 100644 index 0000000..4027d91 --- /dev/null +++ b/www/Documents/Standards/Charter/mar-2005.txt @@ -0,0 +1,97 @@ +The March 2005 R6RS Status Report +================================= + +Consolidation +------------- + +We have voted on a number of the decisions listed in the Revised R6RS +Status Report. Among the minor but visible decisions made are: + +- the addition of multi-line and S-expression comments +- change to case-sensitive lexical syntax +- add balanced square brackets as a synonym for parentheses +- add LETREC* +- specify internal DEFINE in terms of LETREC* +- all datums will be serializable and obey read/write invariance + +Unicode support +--------------- + +We have written up a proposal for Unicode support that defines the +notion of "char" to be a Unicode scalar value---strings are simply +vectors of these scalar values. This allows Unicode support to be +largely a conservative extension of the character and string processing +in R5RS, and avoids the API problems inherent in using a UTF-16-based +representation. Moreover, this approach has already been successfully +implemented by several Scheme implementations. + +Along with Unicode support, we are also considering extensions to the +character and string literal syntax. Details are still under +discussion. + +Exception Handling +------------------ + +An exception handling system has been proposed. Its design is based +on SRFI 34, SRFI 35, with an added condition hierarchy for bugs, in +addition to the hierarchy for errors that is part of SRFI +35. It is too early to say if this proposal will be adopted as there +are interactions with features that remain to be discussed + +Numerical tower +--------------- + +A subcommittee was formed with a mandate to propose revisions to the +numerical tower to the whole committee. While the full proposal is +not yet finished, the subcommittee believes that sets of operations +for exact arithmetic and floating-point arithmetic should be separated +out. The subcommittee is still debating the semantics of the generic +numerical operations, and the issues connected to reading and writing +external representations of numbers. + +Module System +------------- + +The R6RS committee has put significant effort into the module system +issue. Some members of the committee have written strawman proposals. +However, the differences between these proposals is too large to allow +for a simple unification of the systems. We have written up a summary +with a discussion of the various issues, and how they relate to the +various proposals. + +In particular, the proposed module systems all address different sets +of requirements, and hit very different spots on the design spectrum: +presently it seems at least very difficult to address all different +requirements with a single mechanism in the language. + +Specifically, a module system akin to the one in Chez Scheme which is +integrated with the core language, handles the manipulation of +environments in a uniform manner, at the cost of complicating the +static semantics of the language. + +On the other hand, module systems like those of PLT Scheme, Scheme 48 +or Bigloo at least partly reside in a language that is separate from +the core language, thus trading simplicity and easier processing of +the module language for expressive power. + +It would be nice to separate the concerns of environment manipulation +and linking, both of which are in some degree part of all the proposed +module systems. However, this is a technically difficult issue, and +we expect that significant additional effort will be needed to resolve +it. It seems probable that little progress can be made without +significant additional compromise. + +Records +------- + +We expect a system for defining record types to be part of R6RS, and +are exploring the design space for such systems. Two concrete +proposals have been written. + +Procedural issues +----------------- + +A shared CVS archive has been set up to enable work on the actual +document. We're also currently testing video-conferencing to allow +interactive discussions. + diff --git a/www/Documents/Standards/Charter/oct-2004.txt b/www/Documents/Standards/Charter/oct-2004.txt new file mode 100644 index 0000000..a2f1d19 --- /dev/null +++ b/www/Documents/Standards/Charter/oct-2004.txt @@ -0,0 +1,167 @@ + Scheme Standardization + +The following charter and standardization committees have been +approved by the Scheme Strategy Committee. The Strategy Committee was +formed by attendees of the Scheme Workshop in Pittsburgh, October +2002. The draft charter and the committee-selection process were +further confirmed by the attendees of the Scheme Workshop in Boston, +November 2003. + + + Strategy Committee: + Alan Bawden + William Clinger + Kent Dybvig + Matthew Flatt + Richard Kelsey + Manuel Serrano + Michael Sperber + + January 2004 + as amended, October 2004 + + + +Charter +======= + +Standardization Committees +-------------------------- + + * Steering Committee + + The creation of Scheme standards shall be governed by a Steering + Committee that consists of three members. Its responsibility is to + ensure that the standardization process continues, and to establish + processes by which draft standards are reviewed and accepted by + the Scheme community at large. + + The Steering Committee must replace members who + leave. Replacements must be selected within three months, and the + Steering Committee must announce the replacement to the Scheme + community at large. The Steering Committee itself shall establish + procedures for replacing its members. + + This charter can be amended only by a unanimous vote of the + Steering Committee. + + * Standard Editors + + The creation of Scheme standards documents shall be governed by a + committee of seven Editors, including Editor-in-Chief. The + Editor-in-Chief is responsible for producing standardization + documents. None of the Editors may be a member of the Steering + Committee. + + When the Editors have produced a candidate standard, they present + it to the Steering Committee for review and acceptance. The + Steering Committee shall make no rule concerning the process by + which a candidate standard is produced or revised, but Editors are + encouraged to exploit the Scheme Request for Implementation (SRFI) + process for gathering opinions and suggestions from the Scheme + community at large. + + The Steering Committee must replace Editors who leave. The + replacements must be selected within three months, and the Steering + Committee must announce the replacement to the Scheme community at + large. + ++ + +
+ +
1. | Overview | ||||||||||||||||||
2. | Change Log | ||||||||||||||||||
3. | Guiding Principles | ||||||||||||||||||
4. | Decisions | ||||||||||||||||||
| |||||||||||||||||||
5. | Mutability of pairs | ||||||||||||||||||
6. | Reference implementations | ||||||||||||||||||
7. | Work in Progress | ||||||||||||||||||
| |||||||||||||||||||
8. | Completion Process |
+This status report describes the current state of the R6RS +standardization effort. +It covers principles we have outlined to guide the effort, +decisions we have made to date, our work in progress, and the process +by which we intend to complete the Revised6 Report on Scheme. + +
+Here is a brief overview of the important changes to this document since +the February 2006 version. + +
+Section 4.1 provides some examples of libraries +we believe might be required by R6RS. + +
+Section 4.2 (new): describes the forms which portable +code can take. + +
+Section 4.3: now lists interaction-environment, +top-level definitions, and top-level expressions among the eliminated +features. +It also lists scheme-report-environment, +null-environment quotient, remainder, and +modulo among those that have been relegated to an R5RS +compatibility library. + +
+Section 4.4 lists several additional changes. +(All but the first four listed are new.) + +
+Section 4.5 lists several added features. +(All but the first six listed are new.) + +
+Section 4.6 lists two new features to be +added: scripts and a byte-vector datatype. +Read/write invariance is now covered in Section 4.4. + +
+Section 4.7 lists several newly reaffirmed features. +(All but the first three listed are new.) + +
+Section 4.8 lists several features that are officially +not under consideration for R6RS. +(All but the first four listed are new.) + +
+Section 5 announces that the editors have decided +to reconsider whether to make pairs immutable and may even consider +whether to require that the second argument of cons be a list. + +
+Section 6 (new) describes the editors' commitment to provide +reference implementations for the major subsystems included in R6RS. + +
+Section 7.2 documents that we have now withdrawn the +record SRFI as planned, after receiving valuable community input, and that +support for records will be based on this SRFI. +It also describes decisions we have made regarding some issues left +open by the SRFI. + +
+Section 7.3 documents that we have now withdrawn the +Unicode SRFI as planned, after receiving valuable community input, and +that support for Unicode will be based on this SRFI. + +
+Section 7.4 documents that the arithmetic SRFI +has undergone revisions. + +
+Section 7.5 documents that we have decided to base the +R6RS exception system on +SRFI's 34 +and 35. + +
+Section 7.6 documents that we have decided to base the +R6RS I/O system on +SRFI's 79 +and 81. + +
+Section 7.8 (new) documents that we have decided to +base R6RS byte vectors on +SRFI 74. + +
+Section 7.9 now lists enumerations and +eval among possible features and changes. +Some of the previously listed items are no longer under consideration +and are now listed as "beyond R6RS" in Section 4.8: + +
+
+One is now mentioned in Section 4.1: + +
+
+One is now mentioned in Section 4.7: + +
+
+Some are listed as changes to be made, features added, or features to be added: + +
+
+Section 8 now lists Sperber and Clinger as the editors +in charge of byte vectors. + +
+To help guide the standardization effort, the editors have adopted a +set of principles, presented below. +They are, like R6RS itself, a work in progress and still subject +to change. + +
+Like R5RS Scheme, R6RS Scheme should: + +
+
+
+
+
+
+
+
+In addition, R6RS Scheme should: + +
+
+
+
+
+In general, R6RS should include building blocks that allow a wide +variety of libraries to be written, include commonly used user-level +features to enhance portability and readability of library and application +code, and exclude features that are less commonly used and easily +implemented in separate libraries. + +
+R6RS Scheme should also be backward compatible with programs +written in R5RS Scheme to the extent possible without compromising +the above principles and future viability of the language. +With respect to future viability, we operate under the assumption that +many more Scheme programs will be written in the future than exist in +the present, so the future programs are those with which we must be +most concerned. + +
+This section outlines the decisions made to date. + +
+The R6RS language consists of a core language and a set of additional +libraries. +The exact composition of the core language is expected to fluctuate as +other features of R6RS are finalized. + +
+Some examples of the kind of libraries which R6RS might specify are as +follows: + +
+
+R6RS programs exist only in the form of libraries and scripts. +A library consists of a single top-level library form. +Libraries may import variable and keyword bindings from other +libraries (standard or user-defined) and may export variable and keyword +bindings. +A script consists of a standard script header and a single +top-level library. +All definitions and expressions must appear within a library form; +R6RS has no notion of a top-level definition or expression. +The eval procedure will likely, however, allow the +evaluation of an expression (but not a definition) within the scope of a +specified set of library bindings. + +
+The following features of R5RS have been eliminated. + +
+
+The following features of R5RS are deprecated but will be available in +an R5RS compatibility library: + +
+
+The following syntactic and semantic changes have been made to existing +features. + +
+
+The following features have been added: + +
+
+The following features will be added, but the details have yet to be fully +worked out. + +
+
+The following features of R5RS are reaffirmed for R6RS. + +
+
+The following features are definitely not under consideration for R6RS. +We encourage anyone interested in seeing any of these features in R7RS +to make concrete proposals via the SRFI process. + +
+
+Although set-car! and set-cdr! were previously +reaffirmed (Section 4.7), the editors have decided to +reconsider whether pairs should be immutable in R6RS. +Members of the Scheme community wishing to weigh in on the issue +should contact one of the editors. + +
+Making pairs immutable would simplify argument error checks for some +list-processing operations, simplify the list? predicate, allow +apply not to copy the input list when invoking a procedure with a +dot interface, and allow program improvers to perform deforestation, i.e., +to eliminate some of the intermediate lists allocated when nested mapping, +reversing, appending and similar operations are used. +User-defined record types can be used in place of pairs whenever a mutable +data structure is required. + +
+On the other hand, making pairs immutable is an incompatible change that +would break some existing programs, and mutable pairs are natural building +blocks for various abstractions, like queues and streams. + + +
+A more radical change is to require that the second argument to +cons be a list, i.e., the empty list or a pair. +This would make list? constant time and further simplify argument +error checks for some list-processing operations. +Pairs would become useful only as building blocks for lists, and records +(or vectors) would have to be used for most other purposes for which pairs +are currently used. + +
+The editors will publish, along with the revised report proper, +nonnormative, portable (with implementation-dependent hooks as necessary), +and reasonably efficient reference implementations of the major subsystems +of R6RS, including the library, record, Unicode, arithmetic, +exceptions, I/O, and macro subsystems. +The editors may publish reference implementations of selected +additional features as well. + +
+Most of the standardization effort is currently focused on several +subsystems. +Sections 7.1-7.8 list for +each subsystem any informal requirements the editors have +identified, the current status, and open questions. + +
+In several cases, a subsystem is up for discussion as a SRFI in order to +give the editors a chance to inform the community of the ongoing work +and obtain valuable feedback from the community. +The final mechanism adopted for R6RS may, however, differ in minor +or significant ways from the published SRFI. + +
+A list of other items up for consideration is given in +Section 7.9. +These have not received as much attention to date, usually because they +involve less complex or far-reaching changes or are considered to be of +lower priority. + +
+Informal requirements: + support distribution of portable libraries, + support identification of library location, + namespace management, + export/import of macros, + permit separate but dependent analysis and compilation, + support generation of efficient compiled code, + ability to define new libraries. + +
+Support for libraries is under community discussion via +SRFI 83 (R6RS +Library Syntax). +Two big issues have arisen: the need to clarify phases, +e.g., for compile-time modules that import at +compile-time, and how library names are written +(coding as strings is controversial). +Still up in the air are the extent to which the syntax of +import and export forms is tied down, +what built-in libraries besides r6rs there might +be, and how to support subsetting and supersetting of libraries. + +
+Informal requirements: + disjoint types, + syntactic interface, + mutable fields. + +
+Support for records will be based on +SRFI 76 (R6RS Records), +which has now been withdrawn as planned after revisions based in part on +community input. +While the SRFI did not fully specify the generativity of ordinary record +definitions, we have decided that they should be "run-time" generative +unless declared nongenerative. +We have also eliminated the restriction +that the parent of a nongenerative record be a nongenerative record, +and we decided to keep the "sealed" feature. + +
+Additionally, we have decided to allow an implementation to treat any or +all of its built-in types as records, i.e., record? may or may +not return true for an object of a built-in type. + + +
+Informal requirements: + provision for Unicode characters and + character syntax, Unicode strings and string syntax; Unicode + character I/O; integer->char and char->integer are inverse + operations and support Unicode-specific text encodings; + write/read invariance for every datum, including symbols. + +
+Support for Unicode will be based on +SRFI 75 (R6RS Unicode +data), which has now been withdrawn as planned after revisions based in +part on community input. +See http://srfi.schemers.org/srfi-75/mail-archive/msg00309.html +for a discussion of probable differences between the withdrawn +SRFI and R6RS. + +
+Informal requirements: + support for IEEE zeros, infinities, and NaNs, + clean up behavior of eqv? wrt numbers, + fix certain arithmetic operations, + transparency. + +
+Changes for R6RS arithmetic, including support for fixnum-specific, +flonum-specific, and bitwise operators and IEEE arithmetic, are under +community discussion via +SRFI 77 (Preliminary +Proposal for R6RS Arithmetic), which has recently been revised based in +part on community input. + +
+Informal requirements: + clarify the meaning of "is an error," + view exception handling as a means of communication between + parts of the program. + +
+The editors have decided to adopt +SRFI 34 (Exception Handling +for Programs) as the basis for the R6RS exception-handling system and +SRFI 35 (Conditions) as the +basis for the R6RS condition system. + +
+Informal requirements: + read-byte and write-byte, + ports that support binary I/O, + byte-vector datatype, + block read/write operations. + +
+The editors have decided to adopt +SRFI 79 (Primitive I/O) and +SRFI 81 (Port I/O) as the +basis for the R6RS I/O system. + +
+The byte-vector datatype requirement is addressed by the binary block +datatype (Section 7.8). + +
+Informal requirements: + specify expansion semantics, + specify interaction with modules, + allow procedural transformers, + hygiene-breaking operations, + maintain support for syntax-rules. + +
+The editors have decided to adopt syntax-case as currently +implemented in Chez Scheme and MzScheme, with various differences +to be worked out by Dybvig and Flatt. +Also, the underscore identifier ("_") will no longer be +a pattern variable but instead a special identifier that matches +any input, and underscore will be allowed in place of the keyword +naming a macro in a syntax-rules pattern. + +
+SRFI 93 (R6RS Syntax-Case +Macros) has recently been submitted. + +
+The editors have decided to adopt +SRFI 74 (Octet-Addressed +Binary Blocks) as the basis for byte-vector functionality in R6RS, +with the name bytes replaces the name blob. +In contrast with the SRFI, the contents of +(make-bytes n) is unspecified and an +optional fill argument has been added, as +with make-string and make-vector. + +
+The following possible features and changes have been discussed without +resolution. + +
+
+We intend to deliver a draft R6RS to the Steering Committee by +September 1, 2006. +An initial internal (editors only) draft of R6RS has been created and +reflects most of the decisions the editors have made to date. +This draft will be updated as work wraps up on the major subsystems and +other issues. + +
+For each of the subsystems, the core/library split, and the safe/unsafe +mode mechanism and semantics, we have assigned +a single editor to be responsible for ensuring progress. +We have also assigned one or more additional editors to help. +These assignments are shown below. + +
+
+subsystem | primary editor | additional editors |
+libraries | Flatt | Dybvig |
+records | Sperber | Dybvig, van Straaten |
+arithmetic | Clinger | Sperber |
+Unicode | Flatt | Clinger |
+macros | Dybvig | Flatt |
+exceptions | Sperber | Clinger |
+I/O | Sperber | van Straaten |
+byte vectors | Sperber | Clinger |
+core/library split | van Straaten | Dybvig |
+hash tables | van Straaten | Clinger |
+safe/unsafe mode | Clinger | Sperber |
+ |
+At this point, our discussions will be limited mostly to the major +subsystems and the other possible features and changes described in +Section 7.9. +New issues may also be considered if this can be done without +jeopardizing our goal to submit a draft R6RS to the steering +committee by the target deadline. + +
+Responsibility for making sure that the editors complete their work and +communicate effectively lies with the chair (Dybvig) and responsibility +for completing the R6RS draft lies with the project editor (Sperber). + +
+ + + + diff --git a/www/Documents/Standards/Charter/status-jun-2006/status-jun06.pdf b/www/Documents/Standards/Charter/status-jun-2006/status-jun06.pdf new file mode 100644 index 0000000..9e0b8c3 Binary files /dev/null and b/www/Documents/Standards/Charter/status-jun-2006/status-jun06.pdf differ diff --git a/www/Documents/Standards/Charter/status-jun-2006/status.css b/www/Documents/Standards/Charter/status-jun-2006/status.css new file mode 100644 index 0000000..4ce783f --- /dev/null +++ b/www/Documents/Standards/Charter/status-jun-2006/status.css @@ -0,0 +1,9 @@ +body {background-color: #FFFFFF} + +a:link, a:active, a:visited {color:blue} +a:hover {color:white; background:blue} +a.plain:link, a.plain:active, a.plain:visited {color:blue; text-decoration:none} +a.plain:hover {color:white; text-decoration:none; background:blue} + +table.indent {margin-left: 20px} + diff --git a/www/Documents/Standards/Charter/status-mar-2006.html b/www/Documents/Standards/Charter/status-mar-2006.html new file mode 100644 index 0000000..51f1a95 --- /dev/null +++ b/www/Documents/Standards/Charter/status-mar-2006.html @@ -0,0 +1,677 @@ + + + + +
++ + +
+ +
1. | Overview | ||||||||||||||||
2. | Guiding Principles | ||||||||||||||||
3. | Decisions | ||||||||||||||||
| |||||||||||||||||
4. | Work in Progress | ||||||||||||||||
| |||||||||||||||||
5. | Completion Process |
+This status report describes the current state of the R6RS +standardization effort. +It covers principles we have outlined to guide the effort, +decisions we have made to date, our work in progress, and the process +by which we intend to complete the R6RS. + +
+To help guide the standardization effort, the editors have adopted a +set of principles, presented below. +They are, like R6RS itself, a work in progress and still subject +to change. + +
+Like R5RS Scheme, R6RS Scheme should: + +
+
+
+
+
+
+
+
+In addition, R6RS Scheme should: + +
+
+
+
+
+In general, R6RS should include building blocks that allow a wide +variety of libraries to be written, include commonly used user-level +features to enhance portability and readability of library and application +code, and exclude features that are less commonly used and easily +implemented in separate libraries. + +
+R6RS Scheme should also be backward compatible with programs +written in R5RS Scheme to the extent possible without compromising +the above principles and future viability of the language. +With respect to future viability, we operate under the assumption that +many more Scheme programs will be written in the future than exist in +the present, so the future programs are those with which we must be +most concerned. + +
+This section outlines the decisions made to date. + +
+R6RS will consist of a core language and set of separate libraries. + + +
+The following features are definitely in the core language: + +
+
+The following features are definitely in a separate library. + +
+
+The following features have been eliminated. + +
+
+The following syntactic and semantic changes have been made to existing +features. + +
+
+The following features have been added. + +
+
+The following features will be added once the details have been worked out. + +
+
+The following features of R5RS are reaffirmed for R6RS. + +
+
+The following features are definitely not under consideration for R6RS. + +
+
+Most of the standardization effort is currently focused on several +subsystems: libraries, records, Unicode, arithmetic, exceptions, I/O, +modules, and hash tables. +Sections 4.1-4.7 list for +each subsystem a set of informal requirements the editors have +identified, the current status, and open questions. + +
+In several cases, a subsystem is up for discussion as a SRFI in order to +give the editors a chance to inform the community of the ongoing work +and obtain valuable feedback from the community. +The final mechanism adopted for R6RS may, however, differ in minor +or significant ways from the published SRFI. + +
+A list of other items up for consideration is given in +Section 4.8. +These have not received as much attention to date, usually because they +involve less complex or far-reaching changes or are considered to be of +lower priority. + +
+Informal requirements: + support distribution of portable libraries, + support identification of library location, + namespace management, + export/import of macros, + permit separate but dependent analysis and compilation, + support generation of efficient compiled code, + ability to define new libraries. + +
+Support for libraries is under community discussion via SRFI 83. +Two big issues have arisen: the need to clarify phases, +e.g., for compile-time modules that import at +compile-time, and how library names are written +(coding as strings is controversial). +Still up in the air are the extent to which the syntax of +import and export forms is tied down, +what built-in libraries besides r6rs there might +be, and whether there is to be support for user-defined +libraries. + +
+Informal requirements: + disjoint types, + syntactic interface, + mutable fields. + +
+Support for records is under community discussion via SRFI 76. +Still to be settled is whether generativity should be specified, +e.g., as expand-time or run-time and also whether to elide or +provide a rationale for the "sealed" feature. + +
+Informal requirements: + provision for Unicode characters and + character syntax, Unicode strings and string syntax; Unicode + character I/O; integer->char and char->integer are inverse + operations and support Unicode-specific text encodings; + write/read invariance for every datum, including symbols. + +
+Support for Unicode is under community discussion via SRFI 75. +Open issues include what normalization and character representation +to use. +We will probably use normalization form "C," and +Scheme characters will likely correspond to Unicode scalar values +(which can be represented by a 21-bit fixed-length encoding, but +other representations are also possible). + +
+Informal requirements: + support for IEEE zeros, infinities, and NaNs, + clean up behavior of eqv? wrt numbers, + fix certain arithmetic operations, + transparency. + +
+Changes for R6RS arithmetic are under community discussion via SRFI 77. +There is general agreement to require the full tower and to +require that real? implies an exact zero imaginary part. +Among the open questions are whether fixnum, flonum, exact-only, +and inexact-only operations should be in separate libraries rather +than in the core language. + +
+Informal requirements: + clarify the meaning of "is an error," + view exception handling as a means of communication between + parts of the program. + +
+Proposals for this subsystem are currently under discussion. +No R6RS-specific SRFIs have been published, and no decisions have +been made. +There is, however, general agreement to use SRFI 34 as a basis for +the R6RS exception-handling system. + +
+Informal requirements: + read-byte and write-byte, + ports that support binary I/O, + byte vectors, + block read/write operations. + +
+This subsystem actually addresses two separable issues here: potential +additions changes to I/O and the inclusion of a byte-vector datatype. +The byte-vector datatype is necessary to support block read/write +operations. + +
+Proposals for this subsystem are currently under discussion. +No R6RS-specific SRFIs have been published, and no decisions have +been made. + +
+Informal requirements: + specify expansion semantics, + specify interaction with modules, + allow procedural transformers, + hygiene-breaking operations, + maintain support for syntax-rules. + +
+The editors have decided to adopt syntax-case as currently +implemented in Chez Scheme and Dr. Scheme, with various differences +to be worked out by Dybvig and Flatt. +Also, the underscore identifier ("_") will no longer be +a pattern variable but instead a special identifier that matches +any input, and underscore will be allowed in place of the keyword +naming a macro in a syntax-rules pattern. + + +
+The following possible features and changes have been discussed without +resolution. + +
+
+We intend to deliver a draft R6RS to the Steering Committee by +September 1, 2006. +In order to meet this target, we plan to wrap up work on the various +subsystems, decide on the core language/library split, and create a +rough internal (editors only) draft of the R6RS by mid-June. + +
+For each of the subsystems, the core/library split, and the safe/unsafe +mode mechanism and semantics, we have assigned +a single editor to be responsible for ensuring progress. +We have also assigned one or more additional editors to help. +These assignments are shown below. + +
+
+subsystem | primary editor | additional editors |
+libraries | Flatt | Dybvig |
+records | Sperber | Dybvig, van Straaten |
+arithmetic | Clinger | Sperber |
+Unicode | Flatt | Clinger |
+macros | Dybvig | Flatt |
+exceptions | Sperber | Clinger |
+I/O | Sperber | van Straaten |
+core/library split | van Straaten | Dybvig |
+hash tables | van Straaten | Clinger |
+safe/unsafe mode | Clinger | Sperber |
+ |
+As time permits, we will also discuss as a group the other possible +features and changes described in Section 4.8, +as well as additional ones that may arise, and decide which are to be +incorporated into R6RS. + +
+Responsibility for making sure that the editors complete their work and +communicate effectively lies with the chair (Dybvig) and responsibility +for creating the R6RS drafts lies with the project editor (Sperber). + +
+ + + + diff --git a/www/Documents/Standards/Charter/status-mar-2006.pdf b/www/Documents/Standards/Charter/status-mar-2006.pdf new file mode 100644 index 0000000..c7e9752 Binary files /dev/null and b/www/Documents/Standards/Charter/status-mar-2006.pdf differ diff --git a/www/Documents/Standards/R5RS/HTML/index.html b/www/Documents/Standards/R5RS/HTML/index.html new file mode 100644 index 0000000..df02ad7 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/index.html @@ -0,0 +1,5 @@ + +
diff --git a/www/Documents/Standards/R5RS/HTML/navigation.html b/www/Documents/Standards/R5RS/HTML/navigation.html new file mode 100644 index 0000000..2f45393 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/navigation.html @@ -0,0 +1,182 @@ + + + + ++ +The report gives a defining description of the programming language +Scheme. Scheme is a statically scoped and properly tail-recursive +dialect of the Lisp programming language invented by Guy Lewis +Steele Jr. and Gerald Jay Sussman. It was designed to have an +exceptionally clear and simple semantics and few different ways to +form expressions. A wide variety of programming paradigms, including +imperative, functional, and message passing styles, find convenient +expression in Scheme.
+ +The introduction offers a brief history of the language and of +the report.
+ +The first three chapters present the fundamental ideas of the +language and describe the notational conventions used for describing the +language and for writing programs in the language.
+ +Chapters 4 and 5 describe +the syntax and semantics of expressions, programs, and definitions.
+ +Chapter 6 describes Scheme's built-in +procedures, which include all of the language's data manipulation and +input/output primitives.
+ +Chapter 7 provides a formal syntax for Scheme +written in extended BNF, along with a formal denotational semantics. +An example of the use of the language follows the formal syntax and +semantics.
+ +The report concludes with a list of references and an +alphabetic index.
+ +
+ + +
+ + +
+ + + diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html new file mode 100644 index 0000000..6426f76 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html @@ -0,0 +1,546 @@ + + + +
++ +
+ +This chapter provides formal descriptions of what has already been +described informally in previous chapters of this report.
+ +
+ +
+ +This section provides a formal syntax for Scheme written in an extended +BNF.
+ +All spaces in the grammar are for legibility. Case is insignificant; +for example, #x1A and #X1a are equivalent. <empty> +stands for the empty string.
+ +The following extensions to BNF are used to make the description more +concise: <thing>* means zero or more occurrences of +<thing>; and <thing>+ means at least one +<thing>.
+ +This section describes how individual tokens (identifiers, +numbers, etc.) are formed from sequences of characters. The following +sections describe how expressions and programs are formed from sequences +of tokens.
+ +<Intertoken space> may occur on either side of any token, but not +within a token.
+ +Tokens which require implicit termination (identifiers, numbers, +characters, and dot) may be terminated by any <delimiter>, but not +necessarily by anything else.
+
+The following five characters are reserved for future extensions to the
+language: [
]
{
}
|
+ +
+ + +
+ + +
+ +
+ +
+ +The following rules for <num R>, <complex R>, <real +R>, <ureal R>, <uinteger R>, and <prefix R> +should be replicated for R = 2, 8, 10, +and 16. There are no rules for <decimal 2>, <decimal +8>, and <decimal 16>, which means that numbers containing +decimal points or exponents must be in decimal radix. +
+ +
+ +
+ +
+ +
+ +<Datum> is what the read procedure (section 6.6.2) +successfully parses. Note that any string that parses as an +<expression> will also parse as a <datum>.
+ +
+ +
+ +The following grammar for quasiquote expressions is not context-free. +It is presented as a recipe for generating an infinite number of +production rules. Imagine a copy of the following rules for D = 1, 2, +3, .... D keeps track of the nesting depth.
+ +
+ +In <quasiquotation>s, a <list qq template D> can sometimes +be confused with either an <unquotation D> or a <splicing +unquotation D>. The interpretation as an +<unquotation> or <splicing +unquotation D> takes precedence.
+ +
+ +
+
+ +
+ +
+ + + + + + + + + + + + + + + + + + + + + + +
+ + + + +This section provides a formal denotational semantics for the primitive +expressions of Scheme and selected built-in procedures. The concepts +and notation used here are described in [29]; the notation is +summarized below:
+ +
+ +The reason that expression continuations take sequences of values instead +of single values is to simplify the formal treatment of procedure calls +and multiple return values.
+ +The boolean flag associated with pairs, vectors, and strings will be true +for mutable objects and false for immutable objects.
+ +The order of evaluation within a call is unspecified. We mimic that +here by applying arbitrary permutations permute and unpermute, which must be inverses, to the arguments in a call before +and after they are evaluated. This is not quite right since it suggests, +incorrectly, that the order of evaluation is constant throughout a program (for +any given number of arguments), but it is a closer approximation to the intended +semantics than a left-to-right evaluation would be.
+ +The storage allocator new is implementation-dependent, but it must +obey the following axiom: if new L, then + (new | L) 2 = false.
+ + + + +
+ +The definition of is omitted because an accurate definition of + would complicate the semantics without being very interesting.
+ +If P is a program in which all variables are defined before being +referenced or assigned, then the meaning of P is +
+where I* is the sequence of variables defined in P, P' +is the sequence of expressions obtained by replacing every definition +in P by an assignment, <undefined> is an expression that evaluates +to undefined, and + is the semantic function that assigns meaning to expressions.
+ +
+ + + + + + + + + +
+ +
+ +
+ +
+ + + +
+ +
+ + + + +
+ +
+ +
+ +Definition of deliberately omitted.
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +Here and elsewhere, any expressed value other than undefined may +be used in place of unspecified.
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ + +
+ +
+ +This section gives macro definitions for the derived expression types in +terms of the primitive expression types (literal, variable, call, lambda, +if, set!). See section 6.4 for a possible +definition of delay.
+ +
(define-syntax cond
+ (syntax-rules (else =>)
+ ((cond (else result1 result2 ...))
+ (begin result1 result2 ...))
+ ((cond (test => result))
+ (let ((temp test))
+ (if temp (result temp))))
+ ((cond (test => result) clause1 clause2 ...)
+ (let ((temp test))
+ (if temp
+ (result temp)
+ (cond clause1 clause2 ...))))
+ ((cond (test)) test)
+ ((cond (test) clause1 clause2 ...)
+ (let ((temp test))
+ (if temp
+ temp
+ (cond clause1 clause2 ...))))
+ ((cond (test result1 result2 ...))
+ (if test (begin result1 result2 ...)))
+ ((cond (test result1 result2 ...)
+ clause1 clause2 ...)
+ (if test
+ (begin result1 result2 ...)
+ (cond clause1 clause2 ...)))))
+
+ +
(define-syntax case
+ (syntax-rules (else)
+ ((case (key ...)
+ clauses ...)
+ (let ((atom-key (key ...)))
+ (case atom-key clauses ...)))
+ ((case key
+ (else result1 result2 ...))
+ (begin result1 result2 ...))
+ ((case key
+ ((atoms ...) result1 result2 ...))
+ (if (memv key '(atoms ...))
+ (begin result1 result2 ...)))
+ ((case key
+ ((atoms ...) result1 result2 ...)
+ clause clauses ...)
+ (if (memv key '(atoms ...))
+ (begin result1 result2 ...)
+ (case key clause clauses ...)))))
+
+ +
(define-syntax and
+ (syntax-rules ()
+ ((and) #t)
+ ((and test) test)
+ ((and test1 test2 ...)
+ (if test1 (and test2 ...) #f))))
+
+ +
(define-syntax or
+ (syntax-rules ()
+ ((or) #f)
+ ((or test) test)
+ ((or test1 test2 ...)
+ (let ((x test1))
+ (if x x (or test2 ...))))))
+
+ +
(define-syntax let
+ (syntax-rules ()
+ ((let ((name val) ...) body1 body2 ...)
+ ((lambda (name ...) body1 body2 ...)
+ val ...))
+ ((let tag ((name val) ...) body1 body2 ...)
+ ((letrec ((tag (lambda (name ...)
+ body1 body2 ...)))
+ tag)
+ val ...))))
+
+ +
(define-syntax let*
+ (syntax-rules ()
+ ((let* () body1 body2 ...)
+ (let () body1 body2 ...))
+ ((let* ((name1 val1) (name2 val2) ...)
+ body1 body2 ...)
+ (let ((name1 val1))
+ (let* ((name2 val2) ...)
+ body1 body2 ...)))))
+
+ +The following letrec macro uses the symbol <undefined> +in place of an expression which returns something that when stored in +a location makes it an error to try to obtain the value stored in the +location (no such expression is defined in Scheme). +A trick is used to generate the temporary names needed to avoid +specifying the order in which the values are evaluated. +This could also be accomplished by using an auxiliary macro.
+ +
(define-syntax letrec
+ (syntax-rules ()
+ ((letrec ((var1 init1) ...) body ...)
+ (letrec "generate_temp_names"
+ (var1 ...)
+ ()
+ ((var1 init1) ...)
+ body ...))
+ ((letrec "generate_temp_names"
+ ()
+ (temp1 ...)
+ ((var1 init1) ...)
+ body ...)
+ (let ((var1 <undefined>) ...)
+ (let ((temp1 init1) ...)
+ (set! var1 temp1)
+ ...
+ body ...)))
+ ((letrec "generate_temp_names"
+ (x y ...)
+ (temp ...)
+ ((var1 init1) ...)
+ body ...)
+ (letrec "generate_temp_names"
+ (y ...)
+ (newtemp temp ...)
+ ((var1 init1) ...)
+ body ...))))
+
+ +
(define-syntax begin
+ (syntax-rules ()
+ ((begin exp ...)
+ ((lambda () exp ...)))))
+
+ +The following alternative expansion for begin does not make use of +the ability to write more than one expression in the body of a lambda +expression. In any case, note that these rules apply only if the body +of the begin contains no definitions.
+ +
(define-syntax begin
+ (syntax-rules ()
+ ((begin exp)
+ exp)
+ ((begin exp1 exp2 ...)
+ (let ((x exp1))
+ (begin exp2 ...)))))
+
+ +The following definition +of do uses a trick to expand the variable clauses. +As with letrec above, an auxiliary macro would also work. +The expression (if #f #f) is used to obtain an unspecific +value.
+ +
(define-syntax do
+ (syntax-rules ()
+ ((do ((var init step ...) ...)
+ (test expr ...)
+ command ...)
+ (letrec
+ ((loop
+ (lambda (var ...)
+ (if test
+ (begin
+ (if #f #f)
+ expr ...)
+ (begin
+ command
+ ...
+ (loop (do "step" var step ...)
+ ...))))))
+ (loop init ...)))
+ ((do "step" x)
+ x)
+ ((do "step" x y)
+ y)))
+
+ +
+ +
+ + + diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-11.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-11.html new file mode 100644 index 0000000..31bc0c2 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-11.html @@ -0,0 +1,85 @@ + + + +
++ + +
+ +
+ +
+ +This section enumerates the changes that have been made to Scheme since +the ``Revised4 report'' [6] was published.
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
+ +
|
' is reserved
+for possible future extensions.+ +
+ + + +
+ + +
+ +
+ + + diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-12.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-12.html new file mode 100644 index 0000000..7ef3028 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-12.html @@ -0,0 +1,38 @@ + + + +
++ + +
+ +The Internet Scheme Repository at +
+ +http://www.cs.indiana.edu/scheme-repository/ + |
+ +contains an extensive Scheme bibliography, as well as papers, +programs, implementations, and other material related to Scheme. +
+ + +
+ + + diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-13.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-13.html new file mode 100644 index 0000000..5fd65f2 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-13.html @@ -0,0 +1,145 @@ + + + +
++ + +
+Integrate-system integrates the system +
+of differential equations with the method of Runge-Kutta.
+ +The parameter system-derivative is a function that takes a system +state (a vector of values for the state variables y1, ..., yn) +and produces a system derivative (the values y1/, ..., +yn/). The parameter initial-state provides an initial +system state, and h is an initial guess for the length of the +integration step.
+ +The value returned by integrate-system is an infinite stream of +system states.
+ +
(define integrate-system
+ (lambda (system-derivative initial-state h)
+ (let ((next (runge-kutta-4 system-derivative h)))
+ (letrec ((states
+ (cons initial-state
+ (delay (map-streams next
+ states)))))
+ states))))
+ +Runge-Kutta-4 takes a function, f, that produces a +system derivative from a system state. Runge-Kutta-4 +produces a function that takes a system state and +produces a new system state.
+ +
(define runge-kutta-4
+ (lambda (f h)
+ (let ((*h (scale-vector h))
+ (*2 (scale-vector 2))
+ (*1/2 (scale-vector (/ 1 2)))
+ (*1/6 (scale-vector (/ 1 6))))
+ (lambda (y)
+ ;; y is a system state
+ (let* ((k0 (*h (f y)))
+ (k1 (*h (f (add-vectors y (*1/2 k0)))))
+ (k2 (*h (f (add-vectors y (*1/2 k1)))))
+ (k3 (*h (f (add-vectors y k2)))))
+ (add-vectors y
+ (*1/6 (add-vectors k0
+ (*2 k1)
+ (*2 k2)
+ k3))))))))
+
+(define elementwise
+ (lambda (f)
+ (lambda vectors
+ (generate-vector
+ (vector-length (car vectors))
+ (lambda (i)
+ (apply f
+ (map (lambda (v) (vector-ref v i))
+ vectors)))))))
+
+(define generate-vector
+ (lambda (size proc)
+ (let ((ans (make-vector size)))
+ (letrec ((loop
+ (lambda (i)
+ (cond ((= i size) ans)
+ (else
+ (vector-set! ans i (proc i))
+ (loop (+ i 1)))))))
+ (loop 0)))))
+
+(define add-vectors (elementwise +))
+
+(define scale-vector
+ (lambda (s)
+ (elementwise (lambda (x) (* x s)))))
+ +Map-streams is analogous to map: it applies its first +argument (a procedure) to all the elements of its second argument (a +stream).
+ +
(define map-streams
+ (lambda (f s)
+ (cons (f (head s))
+ (delay (map-streams f (tail s))))))
+ +Infinite streams are implemented as pairs whose car holds the first +element of the stream and whose cdr holds a promise to deliver the rest +of the stream.
+ +
(define head car)
+(define tail
+ (lambda (stream) (force (cdr stream))))
+ +
The following illustrates the use of integrate-system in +integrating the system +
+which models a damped oscillator.
+ +
(define damped-oscillator
+ (lambda (R L C)
+ (lambda (state)
+ (let ((Vc (vector-ref state 0))
+ (Il (vector-ref state 1)))
+ (vector (- 0 (+ (/ Vc (* R C)) (/ Il C)))
+ (/ Vc L))))))
+
+(define the-states
+ (integrate-system
+ (damped-oscillator 10000 1000 .001)
+ '#(1 0)
+ .01))
+ +
+ + +
+ + + + + + +
+ + + diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-14.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-14.html new file mode 100644 index 0000000..9f8e6da --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-14.html @@ -0,0 +1,187 @@ + + + +
++ +
[1] |
+Harold Abelson and Gerald Jay Sussman with Julie Sussman.
+Structure and Interpretation of Computer Programs, second edition.
+MIT Press, Cambridge, 1996. + + |
[2] | Alan Bawden and Jonathan Rees.
+Syntactic closures.
+In Proceedings of the 1988 ACM Symposium on Lisp and
+Functional Programming, pages 86-95. + + |
[3] |
+Robert G. Burger and R. Kent Dybvig.
+Printing floating-point numbers quickly and accurately.
+In Proceedings of the ACM SIGPLAN '96 Conference
+on Programming Language Design and Implementation, pages 108-116. + + |
[4] |
+William Clinger, editor.
+The revised revised report on Scheme, or an uncommon Lisp.
+MIT Artificial Intelligence Memo 848, August 1985.
+Also published as Computer Science Department Technical Report 174,
+Indiana University, June 1985. + + |
[5] | William Clinger.
+How to read floating point numbers accurately.
+In Proceedings of the ACM SIGPLAN '90 Conference
+on Programming Language Design and Implementation, pages 92-101.
+Proceedings published as SIGPLAN Notices 25(6), June 1990. + + |
[6] |
+William Clinger and Jonathan Rees, editors.
+The revised4 report on the algorithmic language Scheme.
+In ACM Lisp Pointers 4(3), pages 1-55, 1991. + + |
[7] | William Clinger and Jonathan Rees.
+Macros that work.
+In Proceedings of the 1991 ACM Conference on Principles of
+Programming Languages, pages 155-162. + + |
[8] | William Clinger.
+Proper Tail Recursion and Space Efficiency.
+To appear in Proceedings of the 1998 ACM Conference on Programming
+Language Design and Implementation, June 1998. + + |
[9] |
+R. Kent Dybvig, Robert Hieb, and Carl Bruggeman.
+Syntactic abstraction in Scheme.
+Lisp and Symbolic Computation 5(4):295-326, 1993. + + |
[10] |
+Carol Fessenden, William Clinger, Daniel P. Friedman, and Christopher Haynes.
+Scheme 311 version 4 reference manual.
+Indiana University Computer Science Technical Report 137, February 1983.
+Superseded by [11]. + + |
[11] |
+D. Friedman, C. Haynes, E. Kohlbecker, and M. Wand.
+Scheme 84 interim reference manual.
+Indiana University Computer Science Technical Report 153, January 1985. + + |
[12] |
+IEEE Standard 754-1985. IEEE Standard for Binary Floating-Point
+Arithmetic. IEEE, New York, 1985. + + |
[13] |
+IEEE Standard 1178-1990. IEEE Standard for the Scheme
+Programming Language. IEEE, New York, 1991. + + |
[14] |
+Eugene E. Kohlbecker Jr.
+Syntactic Extensions in the Programming Language Lisp.
+PhD thesis, Indiana University, August 1986. + + |
[15] |
+Eugene E. Kohlbecker Jr., Daniel P. Friedman, Matthias Felleisen, and Bruce Duba.
+Hygienic macro expansion.
+In Proceedings of the 1986 ACM Conference on Lisp
+and Functional Programming, pages 151-161. + + |
[16] |
+Peter Landin.
+A correspondence between Algol 60 and Church's lambda notation: Part I.
+Communications of the ACM 8(2):89-101, February 1965. + + |
[17] |
+MIT Department of Electrical Engineering and Computer Science.
+Scheme manual, seventh edition.
+September 1984. + + |
[18] |
+Peter Naur et al.
+Revised report on the algorithmic language Algol 60.
+Communications of the ACM 6(1):1-17, January 1963. + + |
[19] |
+Paul Penfield, Jr.
+Principal values and branch cuts in complex APL.
+In APL '81 Conference Proceedings, pages 248-256.
+ACM SIGAPL, San Francisco, September 1981.
+Proceedings published as APL Quote Quad 12(1), ACM, September 1981. + + |
[20] |
+Kent M. Pitman.
+The revised MacLisp manual (Saturday evening edition).
+MIT Laboratory for Computer Science Technical Report 295, May 1983. + + |
[21] |
+Jonathan A. Rees and Norman I. Adams IV.
+T: A dialect of Lisp or, lambda: The ultimate software tool.
+In Conference Record of the 1982 ACM Symposium on Lisp and
+Functional Programming, pages 114-122. + + |
[22] |
+Jonathan A. Rees, Norman I. Adams IV, and James R. Meehan.
+The T manual, fourth edition.
+Yale University Computer Science Department, January 1984. + + |
[23] |
+Jonathan Rees and William Clinger, editors.
+The revised3 report on the algorithmic language Scheme.
+In ACM SIGPLAN Notices 21(12), pages 37-79, December 1986. + + |
[24] |
+John Reynolds.
+Definitional interpreters for higher order programming languages.
+In ACM Conference Proceedings, pages 717-740.
+ACM, 1972. + + |
[25] |
+Guy Lewis Steele Jr. and Gerald Jay Sussman.
+The revised report on Scheme, a dialect of Lisp.
+MIT Artificial Intelligence Memo 452, January 1978. + + |
[26] |
+Guy Lewis Steele Jr.
+Rabbit: a compiler for Scheme.
+MIT Artificial Intelligence Laboratory Technical Report 474, May 1978. + + |
[27] |
+Guy Lewis Steele Jr.
+Common Lisp: The Language, second edition.
+Digital Press, Burlington MA, 1990. + + |
[28] |
+Gerald Jay Sussman and Guy Lewis Steele Jr.
+Scheme: an interpreter for extended lambda calculus.
+MIT Artificial Intelligence Memo 349, December 1975. + + |
[29] |
+Joseph E. Stoy.
+Denotational Semantics: The Scott-Strachey Approach to
+Programming Language Theory.
+MIT Press, Cambridge, 1977. + + |
[30] |
+Texas Instruments, Inc.
+TI Scheme Language Reference Manual.
+Preliminary version 1.0, November 1985. + + |
+ + + diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-15.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-15.html new file mode 100644 index 0000000..7ed5256 --- /dev/null +++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-15.html @@ -0,0 +1,430 @@ + + + +
++Alphabetic Index of Definitions of Concepts, +Keywords, and Procedures
+ + +
+ +
+ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-2.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-2.html
new file mode 100644
index 0000000..bbd8ca4
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-2.html
@@ -0,0 +1,134 @@
+
+
+
+
+Contents
+
+
+ Summary
+ Introduction
+ 1 Overview of Scheme
+ 2 Lexical conventions
+ 3 Basic concepts
+ 4 Expressions
+ 5 Program structure
+ 6 Standard procedures
+ 7 Formal syntax and semantics
+ Notes
+ Example
+ Bibliography
+ Alphabetic Index of Definitions of Concepts,
+Keywords, and Procedures
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html
new file mode 100644
index 0000000..3f5d589
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html
@@ -0,0 +1,132 @@
+
+
+
+
+
+
+
+
+
+
+Programming languages should be designed not by piling feature on top of
+feature, but by removing the weaknesses and restrictions that make additional
+features appear necessary. Scheme demonstrates that a very small number
+of rules for forming expressions, with no restrictions on how they are
+composed, suffice to form a practical and efficient programming language
+that is flexible enough to support most of the major programming
+paradigms in use today.
+
+Scheme
+was one of the first programming languages to incorporate first class
+procedures as in the lambda calculus, thereby proving the usefulness of
+static scope rules and block structure in a dynamically typed language.
+Scheme was the first major dialect of Lisp to distinguish procedures
+from lambda expressions and symbols, to use a single lexical
+environment for all variables, and to evaluate the operator position
+of a procedure call in the same way as an operand position. By relying
+entirely on procedure calls to express iteration, Scheme emphasized the
+fact that tail-recursive procedure calls are essentially goto's that
+pass arguments. Scheme was the first widely used programming language to
+embrace first class escape procedures, from which all previously known
+sequential control structures can be synthesized. A subsequent
+version of Scheme introduced the concept of exact and inexact numbers,
+an extension of Common Lisp's generic arithmetic.
+More recently, Scheme became the first programming language to support
+hygienic macros, which permit the syntax of a block-structured language
+to be extended in a consistent and reliable manner.
+
+
+
+The first description of Scheme was written in
+1975 [28]. A revised report [25]
+ appeared in 1978, which described the evolution
+of the language as its MIT implementation was upgraded to support an
+innovative compiler [26]. Three distinct projects began in
+1981 and 1982 to use variants of Scheme for courses at MIT, Yale, and
+Indiana University [21, 17, 10]. An introductory
+computer science textbook using Scheme was published in
+1984 [1].
+
+As Scheme became more widespread,
+local dialects began to diverge until students and researchers
+occasionally found it difficult to understand code written at other
+sites.
+Fifteen representatives of the major implementations of Scheme therefore
+met in October 1984 to work toward a better and more widely accepted
+standard for Scheme.
+Their report [4]
+was published at MIT and Indiana University in the summer of 1985.
+Further revision took place in the spring of 1986 [23],
+and in the spring of 1988 [6].
+The present report reflects further revisions agreed upon in a meeting
+at Xerox PARC in June 1992.
+
+
+
+
+
+
+We intend this report to belong to the entire Scheme community, and so
+we grant permission to copy it in whole or in part without fee. In
+particular, we encourage implementors of Scheme to use this report as
+a starting point for manuals and other documentation, modifying it as
+necessary.
+
+We would like to thank the following people for their help: Alan Bawden, Michael
+Blair, George Carrette, Andy Cromarty, Pavel Curtis, Jeff Dalton, Olivier Danvy,
+Ken Dickey, Bruce Duba, Marc Feeley,
+Andy Freeman, Richard Gabriel, Yekta Gürsel, Ken Haase, Robert
+Hieb, Paul Hudak, Morry Katz, Chris Lindblad, Mark Meyer, Jim Miller, Jim Philbin,
+John Ramsdell, Mike Shaff, Jonathan Shapiro, Julie Sussman,
+Perry Wagle, Daniel Weise, Henry Wu, and Ozan Yigit.
+We thank Carol Fessenden, Daniel
+Friedman, and Christopher Haynes for permission to use text from the Scheme 311
+version 4 reference manual. We thank Texas Instruments, Inc. for permission to
+use text from the TI Scheme Language Reference Manual[30].
+We gladly acknowledge the influence of manuals for MIT Scheme[17],
+T[22], Scheme 84[11],Common Lisp[27],
+and Algol 60[18].
+
+We also thank Betty Dexter for the extreme effort she put into
+setting this report in TEX, and Donald Knuth for designing the program
+that caused her troubles.
+
+The Artificial Intelligence Laboratory of the
+Massachusetts Institute of Technology, the Computer Science
+Department of Indiana University, the Computer and Information
+Sciences Department of the University of Oregon, and the NEC Research
+Institute supported the preparation of this report. Support for the MIT
+work was provided in part by
+the Advanced Research Projects Agency of the Department of Defense under Office
+of Naval Research contract N00014-80-C-0505. Support for the Indiana
+University work was provided by NSF grants NCS 83-04567 and NCS
+83-03325.
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
new file mode 100644
index 0000000..b1be3ce
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
@@ -0,0 +1,288 @@
+
+
+
+
+
+
+
+This section gives an overview of Scheme's semantics. A
+detailed informal semantics is the subject of
+chapters 3 through 6. For reference
+purposes, section 7.2 provides a formal
+semantics of Scheme.
+
+Following Algol, Scheme is a statically scoped programming
+language. Each use of a variable is associated with a lexically
+apparent binding of that variable.
+
+Scheme has latent as opposed to manifest types. Types
+are associated with values (also called objects) rather than
+with variables. (Some authors refer to languages with latent types as
+weakly typed or dynamically typed languages.) Other languages with
+latent types are APL, Snobol, and other dialects of Lisp. Languages
+with manifest types (sometimes referred to as strongly typed or
+statically typed languages) include Algol 60, Pascal, and C.
+
+All objects created in the course of a Scheme computation, including
+procedures and continuations, have unlimited extent.
+No Scheme object is ever destroyed. The reason that
+implementations of Scheme do not (usually!) run out of storage is that
+they are permitted to reclaim the storage occupied by an object if
+they can prove that the object cannot possibly matter to any future
+computation. Other languages in which most objects have unlimited
+extent include APL and other Lisp dialects.
+
+Implementations of Scheme are required to be properly tail-recursive.
+This allows the execution of an iterative computation in constant space,
+even if the iterative computation is described by a syntactically
+recursive procedure. Thus with a properly tail-recursive implementation,
+iteration can be expressed using the ordinary procedure-call
+mechanics, so that special iteration constructs are useful only as
+syntactic sugar. See section 3.5.
+
+Scheme procedures are objects in their own right. Procedures can be
+created dynamically, stored in data structures, returned as results of
+procedures, and so on. Other languages with these properties include
+Common Lisp and ML.
+
+One distinguishing feature of Scheme is that continuations, which
+in most other languages only operate behind the scenes, also have
+``first-class'' status. Continuations are useful for implementing a
+wide variety of advanced control constructs, including non-local exits,
+backtracking, and coroutines. See section 6.4.
+
+Arguments to Scheme procedures are always passed by value, which
+means that the actual argument expressions are evaluated before the
+procedure gains control, whether the procedure needs the result of the
+evaluation or not. ML, C, and APL are three other languages that always
+pass arguments by value.
+This is distinct from the lazy-evaluation semantics of Haskell,
+or the call-by-name semantics of Algol 60, where an argument
+expression is not evaluated unless its value is needed by the
+procedure.
+
+
+
+Scheme's model of arithmetic is designed to remain as independent as
+possible of the particular ways in which numbers are represented within a
+computer. In Scheme, every integer is a rational number, every rational is a
+real, and every real is a complex number. Thus the distinction between integer
+and real arithmetic, so important to many programming languages, does not
+appear in Scheme. In its place is a distinction between exact arithmetic,
+which corresponds to the mathematical ideal, and inexact arithmetic on
+approximations. As in Common Lisp, exact arithmetic is not limited to
+integers.
+
+Scheme, like most dialects of Lisp, employs a fully parenthesized prefix
+notation for programs and (other) data; the grammar of Scheme generates a
+sublanguage of the language used for data. An important
+consequence of this simple, uniform representation is the susceptibility of
+Scheme programs and data to uniform treatment by other Scheme programs.
+For example, the eval procedure evaluates a Scheme program expressed
+as data.
+
+The read procedure performs syntactic as well as lexical decomposition of
+the data it reads. The read procedure parses its input as data
+(section 7.1.2), not as program.
+
+The formal syntax of Scheme is described in section 7.1.
+
+
+
+It is required that every implementation of Scheme support all
+features that are not marked as being optional. Implementations are
+free to omit optional features of Scheme or to add extensions,
+provided the extensions are not in conflict with the language reported
+here. In particular, implementations must support portable code by
+providing a syntactic mode that preempts no lexical conventions of this
+report.
+
+To aid in understanding and implementing Scheme, some features are marked
+as library. These can be easily implemented in terms of the other,
+primitive, features. They are redundant in the strict sense of
+the word, but they capture common patterns of usage, and are therefore
+provided as convenient abbreviations.
+
+
+When speaking of an error situation, this report uses the phrase ``an
+error is signalled'' to indicate that implementations must detect and
+report the error. If such wording does not appear in the discussion of
+an error, then implementations are not required to detect or report the
+error, though they are encouraged to do so. An error situation that
+implementations are not required to detect is usually referred to simply
+as ``an error.''
+
+For example, it is an error for a procedure to be passed an argument that
+the procedure is not explicitly specified to handle, even though such
+domain errors are seldom mentioned in this report. Implementations may
+extend a procedure's domain of definition to include such arguments.
+
+This report uses the phrase ``may report a violation of an
+implementation restriction'' to indicate circumstances under which an
+implementation is permitted to report that it is unable to continue
+execution of a correct program because of some restriction imposed by the
+implementation. Implementation restrictions are of course discouraged,
+but implementations are encouraged to report violations of implementation
+restrictions.
+
+For example, an implementation may report a violation of an
+implementation restriction if it does not have enough storage to run a
+program.
+
+If the value of an expression is said to be ``unspecified,'' then
+the expression must evaluate to some object without signalling an error,
+but the value depends on the implementation; this report explicitly does
+not say what value should be returned.
+
+
+
+
+
+Chapters 4 and 6 are organized
+into entries. Each entry describes one language feature or a group of
+related features, where a feature is either a syntactic construct or a
+built-in procedure. An entry begins with one or more header lines of the form
+
+
+
+for required, primitive features, or
+
+
+
+where qualifier is either ``library'' or ``optional'' as defined
+in section 1.3.1.
+
+If category is ``syntax'', the entry describes an expression
+type, and the template gives the syntax of the expression type.
+Components of expressions are designated by syntactic variables, which
+are written using angle brackets, for example, <expression>,
+<variable>. Syntactic variables should be understood to denote segments of
+program text; for example, <expression> stands for any string of
+characters which is a syntactically valid expression. The notation
+
+ <thing1> ...
+
+indicates zero or more occurrences of a <thing>, and
+
+ <thing1> <thing2> ...
+
+indicates one or more occurrences of a <thing>.
+
+If category is ``procedure'', then the entry describes a procedure, and
+the header line gives a template for a call to the procedure. Argument
+names in the template are italicized. Thus the header line
+
+
+
+indicates that the built-in procedure vector-ref takes
+two arguments, a vector vector and an exact non-negative integer
+k (see below). The header lines
+
+
+
+indicate that the make-vector procedure must be defined to take
+either one or two arguments.
+
+
+It is an error for an operation to be presented with an argument that it
+is not specified to handle. For succinctness, we follow the convention
+that if an argument name is also the name of a type listed in
+section 3.2, then that argument must be of the named type.
+For example, the header line for vector-ref given above dictates that the
+first argument to vector-ref must be a vector. The following naming
+conventions also imply type restrictions:
+
+
+
+
+
+The symbol ``===>'' used in program examples should be read
+``evaluates to.'' For example,
+
+ (* 5 8) ===> 40
+
+means that the expression (* 5 8) evaluates to the object 40.
+Or, more precisely: the expression given by the sequence of characters
+``(* 5 8)'' evaluates, in the initial environment, to an object
+that may be represented externally by the sequence of characters ``40''. See section 3.3 for a discussion of external
+representations of objects.
+
+By convention, the names of procedures that always return a boolean
+value usually end
+in ``?''. Such procedures are called predicates.
+
+By convention, the names of procedures that store values into previously
+allocated locations (see section 3.4) usually end in
+``!''.
+Such procedures are called mutation procedures.
+By convention, the value returned by a mutation procedure is unspecified.
+
+By convention, ``->'' appears within the names of procedures that
+take an object of one type and return an analogous object of another type.
+For example, list->vector takes a list and returns a vector whose
+elements are the same as those of the list.
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-5.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-5.html
new file mode 100644
index 0000000..56f33c3
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-5.html
@@ -0,0 +1,164 @@
+
+
+
+
+
+This section gives an informal account of some of the lexical
+conventions used in writing Scheme programs. For a formal syntax of
+Scheme, see section 7.1.
+
+Upper and lower case forms of a letter are never distinguished
+except within character and string constants. For example, Foo is
+the same identifier as FOO, and #x1AB is the same number as
+#X1ab.
+
+
+
+Most identifiers allowed by other programming
+languages are also acceptable to Scheme. The precise rules for forming
+identifiers vary among implementations of Scheme, but in all
+implementations a sequence of letters, digits, and ``extended alphabetic
+characters'' that begins with a character that cannot begin a number is
+an identifier. In addition, +, -, and ... are identifiers.
+Here are some examples of identifiers:
+
+ lambda q
+
+Extended alphabetic characters may be used within identifiers as if
+they were letters. The following are extended alphabetic characters:
+
+ ! $ %
+
+See section 7.1.1 for a formal syntax of identifiers.
+
+Identifiers have two uses within Scheme programs:
+
+
+
+
+
+
+
+
+Whitespace characters are spaces and newlines.
+(Implementations typically provide additional whitespace characters such
+as tab or page break.) Whitespace is used for improved readability and
+as necessary to separate tokens from each other, a token being an
+indivisible lexical unit such as an identifier or number, but is
+otherwise insignificant. Whitespace may occur between any two tokens,
+but not within a token. Whitespace may also occur inside a string,
+where it is significant.
+
+A semicolon (;) indicates the start of a
+comment. The comment continues to the
+end of the line on which the semicolon appears. Comments are invisible
+to Scheme, but the end of the line is visible as whitespace. This
+prevents a comment from appearing in the middle of an identifier or
+number.
+
+ ;;; The FACT procedure computes the factorial
+
+
+
+For a description of the notations used for numbers, see
+section 6.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html
new file mode 100644
index 0000000..432bbcd
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html
@@ -0,0 +1,327 @@
+
+
+
+
+
+
+
+
+
+
+An identifier may name a type of syntax, or it may name
+a location where a value can be stored. An identifier that names a type
+of syntax is called a syntactic keyword
+and is said to be bound to that syntax. An identifier that names a
+location is called a variable and is said to be
+bound to that location. The set of all visible
+bindings in effect at some point in a program is
+known as the environment in effect at that point. The value
+stored in the location to which a variable is bound is called the
+variable's value. By abuse of terminology, the variable is sometimes
+said to name the value or to be bound to the value. This is not quite
+accurate, but confusion rarely results from this practice.
+
+
+
+
+
+Certain expression types are used to create new kinds of syntax
+and bind syntactic keywords to those new syntaxes, while other
+expression types create new locations and bind variables to those
+locations. These expression types are called binding constructs.
+
+Those that bind syntactic keywords are listed in section 4.3.
+The most fundamental of the variable binding constructs is the
+lambda expression, because all other variable binding constructs
+can be explained in terms of lambda expressions. The other
+variable binding constructs are let, let*, letrec,
+and do expressions (see sections 4.1.4, 4.2.2, and
+4.2.4).
+
+
+Like Algol and Pascal, and unlike most other dialects of Lisp
+except for Common Lisp, Scheme is a statically scoped language with
+block structure. To each place where an identifier is bound in a program
+there corresponds a region of the program text within which
+the binding is visible. The region is determined by the particular
+binding construct that establishes the binding; if the binding is
+established by a lambda expression, for example, then its region
+is the entire lambda expression. Every mention of an identifier
+refers to the binding of the identifier that established the
+innermost of the regions containing the use. If there is no binding of
+the identifier whose region contains the use, then the use refers to the
+binding for the variable in the top level environment, if any
+(chapters 4 and 6); if there is no
+binding for the identifier,
+it is said to be unbound.
+
+
+
+
+
+
+
+
+
+No object satisfies more than one of the following predicates:
+
+ boolean? pair?
+
+These predicates define the types boolean, pair, symbol, number, char (or character), string, vector, port, and procedure. The empty list is a special
+object of its own type; it satisfies none of the above predicates.
+
+
+
+
+Although there is a separate boolean type,
+any Scheme value can be used as a boolean value for the purpose of a
+conditional test. As explained in section 6.3.1, all
+values count as true in such a test except for #f.
+This report uses the word ``true'' to refer to any
+Scheme value except #f, and the word ``false'' to refer to
+#f.
+
+
+
+An important concept in Scheme (and Lisp) is that of the external
+representation of an object as a sequence of characters. For example,
+an external representation of the integer 28 is the sequence of
+characters ``28'', and an external representation of a list consisting
+of the integers 8 and 13 is the sequence of characters ``(8 13)''.
+
+The external representation of an object is not necessarily unique. The
+integer 28 also has representations ``#e28.000'' and ``#x1c'', and the
+list in the previous paragraph also has the representations ``( 08 13
+)'' and ``(8 . (13 . ()))'' (see section 6.3.2).
+
+Many objects have standard external representations, but some, such as
+procedures, do not have standard representations (although particular
+implementations may define representations for them).
+
+An external representation may be written in a program to obtain the
+corresponding object (see quote, section 4.1.2).
+
+External representations can also be used for input and output. The
+procedure read (section 6.6.2) parses external
+representations, and the procedure write (section 6.6.3)
+generates them. Together, they provide an elegant and powerful
+input/output facility.
+
+Note that the sequence of characters ``(+ 2 6)'' is not an
+external representation of the integer 8, even though it is an
+expression evaluating to the integer 8; rather, it is an external
+representation of a three-element list, the elements of which are the symbol
++ and the integers 2 and 6. Scheme's syntax has the property that
+any sequence of characters that is an expression is also the external
+representation of some object. This can lead to confusion, since it may
+not be obvious out of context whether a given sequence of characters is
+intended to denote data or program, but it is also a source of power,
+since it facilitates writing programs such as interpreters and
+compilers that treat programs as data (or vice versa).
+
+The syntax of external representations of various kinds of objects
+accompanies the description of the primitives for manipulating the
+objects in the appropriate sections of chapter 6.
+
+
+
+Variables and objects such as pairs, vectors, and strings implicitly
+denote locations or sequences of locations. A string, for
+example, denotes as many locations as there are characters in the string.
+(These locations need not correspond to a full machine word.) A new value may be
+stored into one of these locations using the string-set! procedure, but
+the string continues to denote the same locations as before.
+
+An object fetched from a location, by a variable reference or by
+a procedure such as car, vector-ref, or string-ref, is
+equivalent in the sense of eqv? (section 6.1)
+to the object last stored in the location before the fetch.
+
+Every location is marked to show whether it is in use.
+No variable or object ever refers to a location that is not in use.
+Whenever this report speaks of storage being allocated for a variable
+or object, what is meant is that an appropriate number of locations are
+chosen from the set of locations that are not in use, and the chosen
+locations are marked to indicate that they are now in use before the variable
+or object is made to denote them.
+
+In many systems it is desirable for constants (i.e. the values of
+literal expressions) to reside in read-only-memory. To express this, it is
+convenient to imagine that every object that denotes locations is associated
+with a flag telling whether that object is mutable or
+immutable. In such systems literal constants and the strings
+returned by symbol->string are immutable objects, while all objects
+created by the other procedures listed in this report are mutable. It is an
+error to attempt to store a new value into a location that is denoted by an
+immutable object.
+
+
+
+Implementations of Scheme are required to be
+properly tail-recursive.
+Procedure calls that occur in certain syntactic
+contexts defined below are `tail calls'. A Scheme implementation is
+properly tail-recursive if it supports an unbounded number of active
+tail calls. A call is active if the called procedure may still
+return. Note that this includes calls that may be returned from either
+by the current continuation or by continuations captured earlier by
+call-with-current-continuation that are later invoked.
+In the absence of captured continuations, calls could
+return at most once and the active calls would be those that had not
+yet returned.
+A formal definition of proper tail recursion can be found
+in [8].
+
+
+
+Intuitively, no space is needed for an active tail call because the
+continuation that is used in the tail call has the same semantics as the
+continuation passed to the procedure containing the call. Although an improper
+implementation might use a new continuation in the call, a return
+to this new continuation would be followed immediately by a return
+to the continuation passed to the procedure. A properly tail-recursive
+implementation returns to that continuation directly.
+
+Proper tail recursion was one of the central ideas in Steele and
+Sussman's original version of Scheme. Their first Scheme interpreter
+implemented both functions and actors. Control flow was expressed using
+actors, which differed from functions in that they passed their results
+on to another actor instead of returning to a caller. In the terminology
+of this section, each actor finished with a tail call to another actor.
+
+Steele and Sussman later observed that in their interpreter the code
+for dealing with actors was identical to that for functions and thus
+there was no need to include both in the language.
+
+
+
+A tail call is a procedure call that occurs
+in a tail context. Tail contexts are defined inductively. Note
+that a tail context is always determined with respect to a particular lambda
+expression.
+
+ (lambda <formals>
+
+
+ (if <expression> <tail expression> <tail expression>)
+
+
+
+
+Certain built-in procedures are also required to perform tail calls.
+The first argument passed to apply and to
+call-with-current-continuation, and the second argument passed to
+call-with-values, must be called via a tail call.
+Similarly, eval must evaluate its argument as if it
+were in tail position within the eval procedure.
+
+In the following example the only tail call is the call to f.
+None of the calls to g or h are tail calls. The reference to
+x is in a tail context, but it is not a call and thus is not a
+tail call.
+ (lambda ()
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html
new file mode 100644
index 0000000..4a2ab4f
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html
@@ -0,0 +1,1023 @@
+
+
+
+
+
+
+
+
+
+
+
+Expression types are categorized as primitive or derived.
+Primitive expression types include variables and procedure calls.
+Derived expression types are not semantically primitive, but can instead
+be defined as macros.
+With the exception of quasiquote, whose macro definition is complex,
+the derived expressions are classified as library features.
+Suitable definitions are given in section 7.3.
+
+
+
+
+
+
+
+An expression consisting of a variable
+(section 3.1) is a variable reference. The value of
+the variable reference is the value stored in the location to which the
+variable is bound. It is an error to reference an
+unbound variable.
+
+ (define x 28)
+
+
+
+
+
+
+(quote <datum>) evaluates to <datum>.
+<Datum>
+may be any external representation of a Scheme object (see
+section 3.3). This notation is used to include literal
+constants in Scheme code.
+
+ (quote a) ===> a
+
+(quote <datum>) may be abbreviated as
+'<datum>. The two notations are equivalent in all
+respects.
+
+ 'a ===> a
+
+Numerical constants, string constants, character constants, and boolean
+constants evaluate ``to themselves''; they need not be quoted.
+
+ '"abc" ===> "abc"
+
+As noted in section 3.4, it is an error to alter a constant
+(i.e. the value of a literal expression) using a mutation procedure like
+set-car! or string-set!.
+
+
+
+
+
+
+
+A procedure call is written by simply enclosing in parentheses
+expressions for the procedure to be called and the arguments to be
+passed to it. The operator and operand expressions are evaluated (in an
+unspecified order) and the resulting procedure is passed the resulting
+arguments.
+ (+ 3 4) ===> 7
+
+A number of procedures are available as the values of variables in the
+initial environment; for example, the addition and multiplication
+procedures in the above examples are the values of the variables +
+and *. New procedures are created by evaluating lambda expressions
+(see section 4.1.4).
+
+
+Procedure calls may return any number of values (see values in
+section 6.4). With the exception of values
+the procedures available in the initial environment return one
+value or, for procedures such as apply, pass on the values returned
+by a call to one of their arguments.
+
+Procedure calls are also called combinations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Syntax: <Formals> should be a formal arguments list as described below,
+and <body> should be a sequence of one or more expressions.
+
+Semantics: A lambda expression evaluates to a procedure. The environment in
+effect when the lambda expression was evaluated is remembered as part of the
+procedure. When the procedure is later called with some actual
+arguments, the environment in which the lambda expression was evaluated will
+be extended by binding the variables in the formal argument list to
+fresh locations, the corresponding actual argument values will be stored
+in those locations, and the expressions in the body of the lambda expression
+will be evaluated sequentially in the extended environment.
+The result(s) of the last expression in the body will be returned as
+the result(s) of the procedure call.
+
+ (lambda (x) (+ x x)) ===> a procedure
+
+<Formals> should have one of the following forms:
+
+
+
+
+
+
+
+It is an error for a <variable> to appear more than once in
+<formals>.
+
+ ((lambda x x) 3 4 5 6) ===> (3 4 5 6)
+
+Each procedure created as the result of evaluating a lambda expression is
+(conceptually) tagged
+with a storage location, in order to make eqv? and
+eq? work on procedures (see section 6.1).
+
+
+
+
+
+
+
+Semantics: An if expression is evaluated as follows: first,
+<test> is evaluated. If it yields a true value (see
+section 6.3.1), then <consequent> is evaluated and
+its value(s) is(are) returned. Otherwise <alternate> is evaluated and its
+value(s) is(are) returned. If <test> yields a false value and no
+<alternate> is specified, then the result of the expression is
+unspecified.
+
+ (if (> 3 2) 'yes 'no) ===> yes
+
+
+
+
+
+
+
+<Expression> is evaluated, and the resulting value is stored in
+the location to which <variable> is bound. <Variable> must
+be bound either in some region enclosing the set! expression
+or at top level. The result of the set! expression is
+unspecified.
+
+ (define x 2)
+
+
+
+
+
+The constructs in this section are hygienic, as discussed in
+section 4.3.
+For reference purposes, section 7.3 gives macro definitions
+that will convert most of the constructs described in this section
+into the primitive constructs described in the previous section.
+
+
+
+
+
+
+
+Syntax: Each <clause> should be of the form
+ (<test> <expression1> ...)
+where <test> is any expression. Alternatively, a <clause> may be
+of the form
+ (<test> => <expression>)
+The last <clause> may be
+an ``else clause,'' which has the form
+ (else <expression1> <expression2> ...).
+
+Semantics: A cond expression is evaluated by evaluating the <test>
+expressions of successive <clause>s in order until one of them
+evaluates to a true value (see
+section 6.3.1). When a <test> evaluates to a true
+value, then the remaining <expression>s in its <clause> are
+evaluated in order, and the result(s) of the last <expression> in the
+<clause> is(are) returned as the result(s) of the entire cond
+expression. If the selected <clause> contains only the
+<test> and no <expression>s, then the value of the
+<test> is returned as the result. If the selected <clause> uses the
+=> alternate form, then the <expression> is evaluated.
+Its value must be a procedure that accepts one argument; this procedure is then
+called on the value of the <test> and the value(s) returned by this
+procedure is(are) returned by the cond expression.
+If all <test>s evaluate
+to false values, and there is no else clause, then the result of
+the conditional expression is unspecified; if there is an else
+clause, then its <expression>s are evaluated, and the value(s) of
+the last one is(are) returned.
+
+ (cond ((> 3 2) 'greater)
+
+
+
+
+
+Syntax: <Key> may be any expression. Each <clause> should have
+the form
+ ((<datum1> ...) <expression1> <expression2> ...),
+where each <datum> is an external representation of some object.
+All the <datum>s must be distinct.
+The last <clause> may be an ``else clause,'' which has the form
+ (else <expression1> <expression2> ...).
+
+Semantics: A case expression is evaluated as follows. <Key> is
+evaluated and its result is compared against each <datum>. If the
+result of evaluating <key> is equivalent (in the sense of
+eqv?; see section 6.1) to a <datum>, then the
+expressions in the corresponding <clause> are evaluated from left
+to right and the result(s) of the last expression in the <clause> is(are)
+returned as the result(s) of the case expression. If the result of
+evaluating <key> is different from every <datum>, then if
+there is an else clause its expressions are evaluated and the
+result(s) of the last is(are) the result(s) of the case expression;
+otherwise the result of the case expression is unspecified.
+
+ (case (* 2 3)
+
+
+
+
+
+The <test> expressions are evaluated from left to right, and the
+value of the first expression that evaluates to a false value (see
+section 6.3.1) is returned. Any remaining expressions
+are not evaluated. If all the expressions evaluate to true values, the
+value of the last expression is returned. If there are no expressions
+then #t is returned.
+
+ (and (= 2 2) (> 2 1)) ===> #t
+
+
+
+
+
+The <test> expressions are evaluated from left to right, and the value of the
+first expression that evaluates to a true value (see
+section 6.3.1) is returned. Any remaining expressions
+are not evaluated. If all expressions evaluate to false values, the
+value of the last expression is returned. If there are no
+expressions then #f is returned.
+
+ (or (= 2 2) (> 2 1)) ===> #t
+
+
+
+The three binding constructs let, let*, and letrec
+give Scheme a block structure, like Algol 60. The syntax of the three
+constructs is identical, but they differ in the regions they establish
+for their variable bindings. In a let expression, the initial
+values are computed before any of the variables become bound; in a
+let* expression, the bindings and evaluations are performed
+sequentially; while in a letrec expression, all the bindings are in
+effect while their initial values are being computed, thus allowing
+mutually recursive definitions.
+
+
+
+Syntax: <Bindings> should have the form
+ ((<variable1> <init1>) ...),
+where each <init> is an expression, and <body> should be a
+sequence of one or more expressions. It is
+an error for a <variable> to appear more than once in the list of variables
+being bound.
+
+Semantics: The <init>s are evaluated in the current environment (in some
+unspecified order), the <variable>s are bound to fresh locations
+holding the results, the <body> is evaluated in the extended
+environment, and the value(s) of the last expression of <body>
+is(are) returned. Each binding of a <variable> has <body> as its
+region.
+
+ (let ((x 2) (y 3))
+
+See also named let, section 4.2.4.
+
+
+
+
+
+Syntax: <Bindings> should have the form
+ ((<variable1> <init1>) ...),
+and <body> should be a sequence of
+one or more expressions.
+
+Semantics: Let* is similar to let, but the bindings are performed
+sequentially from left to right, and the region of a binding indicated
+by (<variable> <init>) is that part of the let*
+expression to the right of the binding. Thus the second binding is done
+in an environment in which the first binding is visible, and so on.
+
+ (let ((x 2) (y 3))
+
+
+
+
+
+Syntax: <Bindings> should have the form
+ ((<variable1> <init1>) ...),
+and <body> should be a sequence of
+one or more expressions. It is an error for a <variable> to appear more
+than once in the list of variables being bound.
+
+Semantics: The <variable>s are bound to fresh locations holding undefined
+values, the <init>s are evaluated in the resulting environment (in
+some unspecified order), each <variable> is assigned to the result
+of the corresponding <init>, the <body> is evaluated in the
+resulting environment, and the value(s) of the last expression in
+<body> is(are) returned. Each binding of a <variable> has the
+entire letrec expression as its region, making it possible to
+define mutually recursive procedures.
+
+ (letrec ((even?
+
+One restriction on letrec is very important: it must be possible
+to evaluate each <init> without assigning or referring to the value of any
+<variable>. If this restriction is violated, then it is an error. The
+restriction is necessary because Scheme passes arguments by value rather than by
+name. In the most common uses of letrec, all the <init>s are
+lambda expressions and the restriction is satisfied automatically.
+
+
+
+
+
+
+
+
+The <expression>s are evaluated sequentially from left to right,
+and the value(s) of the last <expression> is(are) returned. This
+expression type is used to sequence side effects such as input and
+output.
+
+ (define x 0)
+
+
+
+
+
+
+Do is an iteration construct. It specifies a set of variables to
+be bound, how they are to be initialized at the start, and how they are
+to be updated on each iteration. When a termination condition is met,
+the loop exits after evaluating the <expression>s.
+
+Do expressions are evaluated as follows:
+The <init> expressions are evaluated (in some unspecified order),
+the <variable>s are bound to fresh locations, the results of the
+<init> expressions are stored in the bindings of the
+<variable>s, and then the iteration phase begins.
+
+Each iteration begins by evaluating <test>; if the result is
+false (see section 6.3.1), then the <command>
+expressions are evaluated in order for effect, the <step>
+expressions are evaluated in some unspecified order, the
+<variable>s are bound to fresh locations, the results of the
+<step>s are stored in the bindings of the
+<variable>s, and the next iteration begins.
+
+If <test> evaluates to a true value, then the
+<expression>s are evaluated from left to right and the value(s) of
+the last <expression> is(are) returned. If no <expression>s
+are present, then the value of the do expression is unspecified.
+
+The region of the binding of a <variable>
+consists of the entire do expression except for the <init>s.
+It is an error for a <variable> to appear more than once in the
+list of do variables.
+
+A <step> may be omitted, in which case the effect is the
+same as if (<variable> <init> <variable>) had
+been written instead of (<variable> <init>).
+
+ (do ((vec (make-vector 5))
+
+
+
+
+
+
+``Named let'' is a variant on the syntax of let which provides
+a more general looping construct than do and may also be used to express
+recursions.
+It has the same syntax and semantics as ordinary let
+except that <variable> is bound within <body> to a procedure
+whose formal arguments are the bound variables and whose body is
+<body>. Thus the execution of <body> may be repeated by
+invoking the procedure named by <variable>.
+
+ (let loop ((numbers '(3 -2 1 6 -5))
+
+
+
+
+
+
+
+
+
+The delay construct is used together with the procedure force to
+implement lazy evaluation or call by need.
+(delay <expression>) returns an object called a
+promise which at some point in the future may be asked (by
+the force procedure) to evaluate
+<expression>, and deliver the resulting value.
+The effect of <expression> returning multiple values
+is unspecified.
+
+See the description of force (section 6.4) for a
+more complete description of delay.
+
+
+
+
+
+
+
+``Backquote'' or ``quasiquote'' expressions are useful
+for constructing a list or vector structure when most but not all of the
+desired structure is known in advance. If no
+commas appear within the <qq template>, the result of
+evaluating
+`<qq template> is equivalent to the result of evaluating
+'<qq template>. If a comma appears within the
+<qq template>, however, the expression following the comma is
+evaluated (``unquoted'') and its result is inserted into the structure
+instead of the comma and the expression. If a comma appears followed
+immediately by an at-sign (@), then the following
+expression must evaluate to a list; the opening and closing parentheses
+of the list are then ``stripped away'' and the elements of the list are
+inserted in place of the comma at-sign expression sequence. A comma
+at-sign should only appear within a list or vector <qq template>.
+
+
+ `(list ,(+ 1 2) 4) ===> (list 3 4)
+
+Quasiquote forms may be nested. Substitutions are made only for
+unquoted components appearing at the same nesting level
+as the outermost backquote. The nesting level increases by one inside
+each successive quasiquotation, and decreases by one inside each
+unquotation.
+
+ `(a `(b ,(+ 1 2) ,(foo ,(+ 1 3) d) e) f)
+
+The two notations
+`<qq template> and (quasiquote <qq template>)
+are identical in all respects.
+,<expression> is identical to (unquote <expression>),
+and
+,@<expression> is identical to (unquote-splicing <expression>).
+The external syntax generated by write for two-element lists whose
+car is one of these symbols may vary between implementations.
+
+
+ (quasiquote (list (unquote (+ 1 2)) 4))
+
+Unpredictable behavior can result if any of the symbols
+quasiquote, unquote, or unquote-splicing appear in
+positions within a <qq template> otherwise than as described above.
+
+
+
+
+
+Scheme programs can define and use new derived expression types,
+called macros.
+Program-defined expression types have the syntax
+ (<keyword> <datum> ...) where <keyword> is an identifier that uniquely determines the
+expression type. This identifier is called the syntactic
+keyword, or simply keyword, of the macro. The
+number of the <datum>s, and their syntax, depends on the
+expression type.
+
+Each instance of a macro is called a use
+of the macro.
+The set of rules that specifies
+how a use of a macro is transcribed into a more primitive expression
+is called the transformer
+of the macro.
+
+The macro definition facility consists of two parts:
+
+
+
+
+
+The syntactic keyword of a macro may shadow variable bindings, and local
+variable bindings may shadow keyword bindings. All macros
+defined using the pattern language are ``hygienic'' and ``referentially
+transparent'' and thus preserve Scheme's lexical scoping [14, 15, 2, 7, 9]:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Let-syntax and letrec-syntax are
+analogous to let and letrec, but they bind
+syntactic keywords to macro transformers instead of binding variables
+to locations that contain values. Syntactic keywords may also be
+bound at top level; see section 5.3.
+
+
+
+Syntax: <Bindings> should have the form
+ ((<keyword> <transformer spec>) ...)
+Each <keyword> is an identifier,
+each <transformer spec> is an instance of syntax-rules, and
+<body> should be a sequence of one or more expressions. It is an error
+for a <keyword> to appear more than once in the list of keywords
+being bound.
+
+Semantics: The <body> is expanded in the syntactic environment
+obtained by extending the syntactic environment of the
+let-syntax expression with macros whose keywords are
+the <keyword>s, bound to the specified transformers.
+Each binding of a <keyword> has <body> as its region.
+
+ (let-syntax ((when (syntax-rules ()
+
+
+
+
+
+Syntax: Same as for let-syntax.
+
+Semantics: The <body> is expanded in the syntactic environment obtained by
+extending the syntactic environment of the letrec-syntax
+expression with macros whose keywords are the
+<keyword>s, bound to the specified transformers.
+Each binding of a <keyword> has the <bindings>
+as well as the <body> within its region,
+so the transformers can
+transcribe expressions into uses of the macros
+introduced by the letrec-syntax expression.
+
+ (letrec-syntax
+
+
+
+
+
+A <transformer spec> has the following form:
+
+
+
+Syntax: <Literals> is a list of identifiers and each <syntax rule>
+should be of the form
+ (<pattern> <template>)
+The <pattern> in a <syntax rule> is a list <pattern>
+that begins with the keyword for the macro.
+
+A <pattern> is either an identifier, a constant, or one of the
+following
+ (<pattern> ...)
+and a template is either an identifier, a constant, or one of the following
+ (<element> ...)
+where an <element> is a <template> optionally
+followed by an <ellipsis> and
+an <ellipsis> is the identifier ``...'' (which cannot be used as
+an identifier in either a template or a pattern).
+
+Semantics: An instance of syntax-rules produces a new macro
+transformer by specifying a sequence of hygienic rewrite rules. A use
+of a macro whose keyword is associated with a transformer specified by
+syntax-rules is matched against the patterns contained in the
+<syntax rule>s, beginning with the leftmost <syntax rule>.
+When a match is found, the macro use is transcribed hygienically
+according to the template.
+
+An identifier that appears in the pattern of a <syntax rule> is
+a pattern variable, unless it is the keyword that begins the pattern,
+is listed in <literals>, or is the identifier ``...''.
+Pattern variables match arbitrary input elements and
+are used to refer to elements of the input in the template. It is an
+error for the same pattern variable to appear more than once in a
+<pattern>.
+
+The keyword at the beginning of the pattern in a
+<syntax rule> is not involved in the matching and
+is not considered a pattern variable or literal identifier.
+
+
+
+Identifiers that appear in <literals> are interpreted as literal
+identifiers to be matched against corresponding subforms of the input.
+A subform
+in the input matches a literal identifier if and only if it is an
+identifier
+and either both its occurrence in the macro expression and its
+occurrence in the macro definition have the same lexical binding, or
+the two identifiers are equal and both have no lexical binding.
+
+
+A subpattern followed by ... can match zero or more elements of the
+input. It is an error for ... to appear in <literals>.
+Within a pattern the identifier ... must follow the last element of
+a nonempty sequence of subpatterns.
+
+More formally, an input form F matches a pattern P if and only if:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+It is an error to use a macro keyword, within the scope of its
+binding, in an expression that does not match any of the patterns.
+
+When a macro use is transcribed according to the template of the
+matching <syntax rule>, pattern variables that occur in the
+template are replaced by the subforms they match in the input.
+Pattern variables that occur in subpatterns followed by one or more
+instances of the identifier
+... are allowed only in subtemplates that are
+followed by as many instances of ....
+They are replaced in the
+output by all of the subforms they match in the input, distributed as
+indicated. It is an error if the output cannot be built up as
+specified.
+
+
+Identifiers that appear in the template but are not pattern variables
+or the identifier
+... are inserted into the output as literal identifiers. If a
+literal identifier is inserted as a free identifier then it refers to the
+binding of that identifier within whose scope the instance of
+syntax-rules appears.
+If a literal identifier is inserted as a bound identifier then it is
+in effect renamed to prevent inadvertent captures of free identifiers.
+
+As an example, if let and cond are defined as in
+section 7.3 then they are hygienic (as required) and
+the following is not an error.
+
+ (let ((=> #f))
+
+The macro transformer for cond recognizes =>
+as a local variable, and hence an expression, and not as the
+top-level identifier =>, which the macro transformer treats
+as a syntactic keyword. Thus the example expands into
+
+ (let ((=> #f))
+
+instead of
+
+ (let ((=> #f))
+
+which would result in an invalid procedure call.
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-8.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-8.html
new file mode 100644
index 0000000..db3236a
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-8.html
@@ -0,0 +1,198 @@
+
+
+
+
+
+
+
+A Scheme program consists of a sequence of expressions, definitions,
+and syntax definitions.
+Expressions are described in chapter 4;
+definitions and syntax definitions are the subject of the rest of the
+present chapter.
+
+Programs are typically stored in files or entered interactively to a
+running Scheme system, although other paradigms are possible;
+questions of user interface lie outside the scope of this report.
+(Indeed, Scheme would still be useful as a notation for expressing
+computational methods even in the absence of a mechanical
+implementation.)
+
+Definitions and syntax definitions occurring at the top level of a program
+can be interpreted
+declaratively.
+They cause bindings to be created in the top level
+environment or modify the value of existing top-level bindings.
+Expressions occurring at the top level of a program are
+interpreted imperatively; they are executed in order when the program is
+invoked or loaded, and typically perform some kind of initialization.
+
+At the top level of a program (begin <form1> ...) is
+equivalent to the sequence of expressions, definitions, and syntax definitions
+that form the body of the begin.
+
+
+
+
+
+Definitions are valid in some, but not all, contexts where expressions
+are allowed. They are valid only at the top level of a <program>
+and at the beginning of a <body>.
+
+
+A definition should have one of the following forms:
+
+
+
+
+
+
+
+<Formals> should be either a
+sequence of zero or more variables, or a sequence of one or more
+variables followed by a space-delimited period and another variable (as
+in a lambda expression). This form is equivalent to
+ (define <variable>
+
+
+
+<Formal> should be a single
+variable. This form is equivalent to
+ (define <variable>
+
+
+
+At the top level of a program, a definition
+ (define <variable> <expression>)
+has essentially the same effect as the assignment expression
+ (set! <variable> <expression>)
+if <variable> is bound. If <variable> is not bound,
+however, then the definition will bind <variable> to a new
+location before performing the assignment, whereas it would be an error
+to perform a set! on an unbound variable.
+
+ (define add3
+
+Some implementations of Scheme use an initial environment in
+which all possible variables are bound to locations, most of
+which contain undefined values. Top level definitions in
+such an implementation are truly equivalent to assignments.
+
+
+
+
+
+Definitions may occur at the
+beginning of a <body> (that is, the body of a lambda,
+let, let*, letrec, let-syntax, or letrec-syntax
+expression or that of a definition of an appropriate form).
+Such definitions are known as internal definitions as opposed to the top level definitions described above.
+The variable defined by an internal definition is local to the
+<body>. That is, <variable> is bound rather than assigned,
+and the region of the binding is the entire <body>. For example,
+
+ (let ((x 5))
+
+A <body> containing internal definitions can always be converted
+into a completely equivalent letrec expression. For example, the
+let expression in the above example is equivalent to
+
+ (let ((x 5))
+
+Just as for the equivalent letrec expression, it must be
+possible to evaluate each <expression> of every internal
+definition in a <body> without assigning or referring to
+the value of any <variable> being defined.
+
+Wherever an internal definition may occur
+(begin <definition1> ...)
+is equivalent to the sequence of definitions
+that form the body of the begin.
+
+Syntax definitions are valid only at the top level of a <program>.
+
+They have the following form:
+
+(define-syntax <keyword> <transformer spec>)
+
+<Keyword> is an identifier, and
+the <transformer spec> should be an instance of syntax-rules.
+The top-level syntactic environment is extended by binding the
+<keyword> to the specified transformer.
+
+There is no define-syntax analogue of internal definitions.
+
+
+
+Although macros may expand into definitions and syntax definitions in
+any context that permits them, it is an error for a definition or syntax
+definition to shadow a syntactic keyword whose meaning is needed to
+determine whether some form in the group of forms that contains the
+shadowing definition is in fact a definition, or, for internal definitions,
+is needed to determine the boundary between the group and the expressions
+that follow the group. For example, the following are errors:
+
+ (define define 3)
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html
new file mode 100644
index 0000000..815ab1d
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html
@@ -0,0 +1,2900 @@
+
+
+
+
+
+
+
+
+This chapter describes Scheme's built-in procedures. The initial (or
+``top level'') Scheme environment starts out with a number of variables
+bound to locations containing useful values, most of which are primitive
+procedures that manipulate data. For example, the variable abs is
+bound to (a location initially containing) a procedure of one argument
+that computes the absolute value of a number, and the variable +
+is bound to a procedure that computes sums. Built-in procedures that
+can easily be written in terms of other built-in procedures are identified as
+``library procedures''.
+
+A program may use a top-level definition to bind any variable. It may
+subsequently alter any such binding by an assignment (see 4.1.6).
+These operations do not modify the behavior of Scheme's built-in
+procedures. Altering any top-level binding that has not been introduced by a
+definition has an unspecified effect on the behavior of the built-in procedures.
+
+
+
+A predicate is a procedure that always returns a boolean
+value (#t or #f). An equivalence predicate is
+the computational analogue of a mathematical equivalence relation (it is
+symmetric, reflexive, and transitive). Of the equivalence predicates
+described in this section, eq? is the finest or most
+discriminating, and equal? is the coarsest. Eqv? is
+slightly less discriminating than eq?.
+
+
+
+The eqv? procedure defines a useful equivalence relation on objects.
+Briefly, it returns #t if obj1 and obj2 should
+normally be regarded as the same object. This relation is left slightly
+open to interpretation, but the following partial specification of
+eqv? holds for all implementations of Scheme.
+
+The eqv? procedure returns #t if:
+
+
+
+
+
+ (string=? (symbol->string obj1)
+
+
+
+
+
+
+
+
+
+
+
+
+
+The eqv? procedure returns #f if:
+
+
+
+
+
+
+
+ (string=? (symbol->string obj1)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ (eqv? 'a 'a) ===> #t
+
+The following examples illustrate cases in which the above rules do
+not fully specify the behavior of eqv?. All that can be said
+about such cases is that the value returned by eqv? must be a
+boolean.
+
+ (eqv? "" "") ===> unspecified
+
+The next set of examples shows the use of eqv? with procedures
+that have local state. Gen-counter must return a distinct
+procedure every time, since each procedure has its own internal counter.
+Gen-loser, however, returns equivalent procedures each time, since
+the local state does not affect the value or side effects of the
+procedures.
+
+ (define gen-counter
+
+
+Since it is an error to modify constant objects (those returned by
+literal expressions), implementations are permitted, though not
+required, to share structure between constants where appropriate. Thus
+the value of eqv? on constants is sometimes
+implementation-dependent.
+
+ (eqv? '(a) '(a)) ===> unspecified
+
+
+
+
+
+
+
+Eq? is similar to eqv? except that in some cases it is
+capable of discerning distinctions finer than those detectable by
+eqv?.
+
+Eq? and eqv? are guaranteed to have the same
+behavior on symbols, booleans, the empty list, pairs, procedures,
+and non-empty
+strings and vectors. Eq?'s behavior on numbers and characters is
+implementation-dependent, but it will always return either true or
+false, and will return true only when eqv? would also return
+true. Eq? may also behave differently from eqv? on empty
+vectors and empty strings.
+
+ (eq? 'a 'a) ===> #t
+
+
+
+
+
+
+
+
+
+Equal? recursively compares the contents of pairs, vectors, and
+strings, applying eqv? on other objects such as numbers and symbols.
+A rule of thumb is that objects are generally equal? if they print
+the same. Equal? may fail to terminate if its arguments are
+circular data structures.
+
+ (equal? 'a 'a) ===> #t
+
+
+
+
+
+
+
+Numerical computation has traditionally been neglected by the Lisp
+community. Until Common Lisp there was no carefully thought out
+strategy for organizing numerical computation, and with the exception of
+the MacLisp system [20] little effort was made to
+execute numerical code efficiently. This report recognizes the excellent work
+of the Common Lisp committee and accepts many of their recommendations.
+In some ways this report simplifies and generalizes their proposals in a manner
+consistent with the purposes of Scheme.
+
+It is important to distinguish between the mathematical numbers, the
+Scheme numbers that attempt to model them, the machine representations
+used to implement the Scheme numbers, and notations used to write numbers.
+This report uses the types number, complex, real,
+rational, and integer to refer to both mathematical numbers
+and Scheme numbers. Machine representations such as fixed point and
+floating point are referred to by names such as fixnum and
+flonum.
+
+
+
+Mathematically, numbers may be arranged into a tower of subtypes
+in which each level is a subset of the level above it:
+
+ number
+
+For example, 3 is an integer. Therefore 3 is also a rational,
+a real, and a complex. The same is true of the Scheme numbers
+that model 3. For Scheme numbers, these types are defined by the
+predicates number?, complex?, real?, rational?,
+and integer?.
+
+There is no simple relationship between a number's type and its
+representation inside a computer. Although most implementations of
+Scheme will offer at least two different representations of 3, these
+different representations denote the same integer.
+
+
+Scheme's numerical operations treat numbers as abstract data, as
+independent of their representation as possible. Although an implementation
+of Scheme may use fixnum, flonum, and perhaps other representations for
+numbers, this should not be apparent to a casual programmer writing
+simple programs.
+
+It is necessary, however, to distinguish between numbers that are
+represented exactly and those that may not be. For example, indexes
+into data structures must be known exactly, as must some polynomial
+coefficients in a symbolic algebra system. On the other hand, the
+results of measurements are inherently inexact, and irrational numbers
+may be approximated by rational and therefore inexact approximations.
+In order to catch uses of inexact numbers where exact numbers are
+required, Scheme explicitly distinguishes exact from inexact numbers.
+This distinction is orthogonal to the dimension of type.
+
+
+
+Scheme numbers are either exact or inexact. A number is
+exact if it was written as an exact constant or was derived from
+exact numbers using only exact operations. A number is
+inexact if it was written as an inexact constant,
+if it was
+derived using inexact ingredients, or if it was derived using
+inexact operations. Thus inexactness is a contagious
+property of a number.
+
+If two implementations produce exact results for a
+computation that did not involve inexact intermediate results,
+the two ultimate results will be mathematically equivalent. This is
+generally not true of computations involving inexact numbers
+since approximate methods such as floating point arithmetic may be used,
+but it is the duty of each implementation to make the result as close as
+practical to the mathematically ideal result.
+
+Rational operations such as + should always produce
+exact results when given exact arguments.
+If the operation is unable to produce an exact result,
+then it may either report the violation of an implementation restriction
+or it may silently coerce its
+result to an inexact value.
+See section 6.2.3.
+
+With the exception of inexact->exact, the operations described in
+this section must generally return inexact results when given any inexact
+arguments. An operation may, however, return an exact result if it can
+prove that the value of the result is unaffected by the inexactness of its
+arguments. For example, multiplication of any number by an exact zero
+may produce an exact zero result, even if the other argument is
+inexact.
+
+Implementations of Scheme are not required to implement the whole
+tower of subtypes given in section 6.2.1,
+but they must implement a coherent subset consistent with both the
+purposes of the implementation and the spirit of the Scheme language.
+For example, an implementation in which all numbers are real
+may still be quite useful.
+
+Implementations may also support only a limited range of numbers of
+any type, subject to the requirements of this section. The supported
+range for exact numbers of any type may be different from the
+supported range for inexact numbers of that type. For example,
+an implementation that uses flonums to represent all its
+inexact real numbers may
+support a practically unbounded range of exact integers
+and rationals
+while limiting the range of inexact reals (and therefore
+the range of inexact integers and rationals)
+to the dynamic range of the flonum format.
+Furthermore
+the gaps between the representable inexact integers and
+rationals are
+likely to be very large in such an implementation as the limits of this
+range are approached.
+
+An implementation of Scheme must support exact integers
+throughout the range of numbers that may be used for indexes of
+lists, vectors, and strings or that may result from computing the length of a
+list, vector, or string. The length, vector-length,
+and string-length procedures must return an exact
+integer, and it is an error to use anything but an exact integer as an
+index. Furthermore any integer constant within the index range, if
+expressed by an exact integer syntax, will indeed be read as an exact
+integer, regardless of any implementation restrictions that may apply
+outside this range. Finally, the procedures listed below will always
+return an exact integer result provided all their arguments are exact integers
+and the mathematically expected result is representable as an exact integer
+within the implementation:
+
+ + - *
+
+Implementations are encouraged, but not required, to support
+exact integers and exact rationals of
+practically unlimited size and precision, and to implement the
+above procedures and the / procedure in
+such a way that they always return exact results when given exact
+arguments. If one of these procedures is unable to deliver an exact
+result when given exact arguments, then it may either report a
+violation of an
+implementation restriction or it may silently coerce its result to an
+inexact number. Such a coercion may cause an error later.
+
+
+An implementation may use floating point and other approximate
+representation strategies for inexact numbers.
+This report recommends, but does not require, that the IEEE 32-bit
+and 64-bit floating point standards be followed by implementations that use
+flonum representations, and that implementations using
+other representations should match or exceed the precision achievable
+using these floating point standards [12].
+
+In particular, implementations that use flonum representations
+must follow these rules: A flonum result
+must be represented with at least as much precision as is used to express any of
+the inexact arguments to that operation. It is desirable (but not required) for
+potentially inexact operations such as sqrt, when applied to exact
+arguments, to produce exact answers whenever possible (for example the
+square root of an exact 4 ought to be an exact 2).
+If, however, an
+exact number is operated upon so as to produce an inexact result
+(as by sqrt), and if the result is represented as a flonum, then
+the most precise flonum format available must be used; but if the result
+is represented in some other way then the representation must have at least as
+much precision as the most precise flonum format available.
+
+Although Scheme allows a variety of written
+notations for
+numbers, any particular implementation may support only some of them.
+For example, an implementation in which all numbers are real
+need not support the rectangular and polar notations for complex
+numbers. If an implementation encounters an exact numerical constant that
+it cannot represent as an exact number, then it may either report a
+violation of an implementation restriction or it may silently represent the
+constant by an inexact number.
+
+
+
+
+
+The syntax of the written representations for numbers is described formally in
+section 7.1.1. Note that case is not significant in numerical
+constants.
+
+
+A number may be written in binary, octal, decimal, or
+hexadecimal by the use of a radix prefix. The radix prefixes are #b (binary), #o (octal), #d (decimal), and #x (hexadecimal). With
+no radix prefix, a number is assumed to be expressed in decimal.
+
+A
+numerical constant may be specified to be either exact or
+inexact by a prefix. The prefixes are #e
+for exact, and #i for inexact. An exactness
+prefix may appear before or after any radix prefix that is used. If
+the written representation of a number has no exactness prefix, the
+constant may be either inexact or exact. It is
+inexact if it contains a decimal point, an
+exponent, or a ``#'' character in the place of a digit,
+otherwise it is exact.
+
+In systems with inexact numbers
+of varying precisions it may be useful to specify
+the precision of a constant. For this purpose, numerical constants
+may be written with an exponent marker that indicates the
+desired precision of the inexact
+representation. The letters s, f,
+d, and l specify the use of short, single,
+double, and long precision, respectively. (When fewer
+than four internal
+inexact
+representations exist, the four size
+specifications are mapped onto those available. For example, an
+implementation with two internal representations may map short and
+single together and long and double together.) In addition, the
+exponent marker e specifies the default precision for the
+implementation. The default precision has at least as much precision
+as double, but
+implementations may wish to allow this default to be set by the user.
+
+ 3.14159265358979F0
+
+The reader is referred to section 1.3.3 for a summary
+of the naming conventions used to specify restrictions on the types of
+arguments to numerical routines.
+The examples used in this section assume that any numerical constant written
+using an exact notation is indeed represented as an exact
+number. Some examples also assume that certain numerical constants written
+using an inexact notation can be represented without loss of
+accuracy; the inexact constants were chosen so that this is
+likely to be true in implementations that use flonums to represent
+inexact numbers.
+
+
+
+
+
+These numerical type predicates can be applied to any kind of
+argument, including non-numbers. They return #t if the object is
+of the named type, and otherwise they return #f.
+In general, if a type predicate is true of a number then all higher
+type predicates are also true of that number. Consequently, if a type
+predicate is false of a number, then all lower type predicates are
+also false of that number.
+
+If z is an inexact complex number, then (real? z) is true if
+and only if (zero? (imag-part z)) is true. If x is an inexact
+real number, then (integer? x) is true if and only if
+(= x (round x)).
+
+ (complex? 3+4i) ===> #t
+
+
+
+
+
+
+
+
+
+These numerical predicates provide tests for the exactness of a
+quantity. For any Scheme number, precisely one of these predicates
+is true.
+
+
+
+
+
+These procedures return #t if their arguments are (respectively):
+equal, monotonically increasing, monotonically decreasing,
+monotonically nondecreasing, or monotonically nonincreasing.
+
+These predicates are required to be transitive.
+
+
+
+
+
+
+
+
+
+These numerical predicates test a number for a particular property,
+returning #t or #f. See note above.
+
+
+
+
+
+These procedures return the maximum or minimum of their arguments.
+
+ (max 3 4) ===> 4 ; exact
+
+
+
+
+
+
+
+These procedures return the sum or product of their arguments.
+
+ (+ 3 4) ===> 7
+
+
+
+
+
+With two or more arguments, these procedures return the difference or
+quotient of their arguments, associating to the left. With one argument,
+however, they return the additive or multiplicative inverse of their argument.
+
+ (- 3 4) ===> -1
+
+
+
+
+
+Abs returns the absolute value of its argument.
+ (abs -7) ===> 7
+
+
+
+
+These procedures implement number-theoretic (integer)
+division. n2 should be non-zero. All three procedures
+return integers. If n1/n2 is an integer:
+ (quotient n1 n2) ===> n1/n2
+If n1/n2 is not an integer:
+ (quotient n1 n2) ===> nq
+where nq is n1/n2 rounded towards zero,
+0 < |nr| < |n2|, 0 < |nm| < |n2|,
+nr and nm differ from n1 by a multiple of n2,
+nr has the same sign as n1, and
+nm has the same sign as n2.
+
+From this we can conclude that for integers n1 and n2 with
+n2 not equal to 0,
+ (= n1 (+ (* n2 (quotient n1 n2))
+provided all numbers involved in that computation are exact.
+
+ (modulo 13 4) ===> 1
+
+
+
+
+These procedures return the greatest common divisor or least common
+multiple of their arguments. The result is always non-negative.
+
+ (gcd 32 -36) ===> 4
+
+
+
+
+
+These procedures return the numerator or denominator of their
+argument; the result is computed as if the argument was represented as
+a fraction in lowest terms. The denominator is always positive. The
+denominator of 0 is defined to be 1.
+
+ (numerator (/ 6 4)) ===> 3
+
+
+
+
+
+These procedures return integers.
+Floor returns the largest integer not larger than x.
+Ceiling returns the smallest integer not smaller than x.
+Truncate returns the integer closest to x whose absolute
+value is not larger than the absolute value of x. Round returns the
+closest integer to x, rounding to even when x is halfway between two
+integers.
+
+
+
+
+
+ (floor -4.3) ===> -5.0
+
+
+
+
+
+Rationalize returns the simplest rational number
+differing from x by no more than y. A rational number r1 is
+simpler than another rational number
+r2 if r1 = p1/q1 and r2 = p2/q2 (in lowest terms) and |p1|
+< |p2| and |q1| < |q2|. Thus 3/5 is simpler than 4/7.
+Although not all rationals are comparable in this ordering (consider 2/7
+and 3/5) any interval contains a rational number that is simpler than
+every other rational number in that interval (the simpler 2/5 lies
+between 2/7 and 3/5). Note that 0 = 0/1 is the simplest rational of
+all.
+
+ (rationalize
+
+
+
+
+
+These procedures are part of every implementation that supports
+general
+real numbers; they compute the usual transcendental functions. Log
+computes the natural logarithm of z (not the base ten logarithm).
+Asin, acos, and atan compute arcsine (sin-1),
+arccosine (cos-1), and arctangent (tan-1), respectively.
+The two-argument variant of atan computes (angle
+(make-rectangular x y)) (see below), even in implementations
+that don't support general complex numbers.
+
+In general, the mathematical functions log, arcsine, arccosine, and
+arctangent are multiply defined.
+The value of log z is defined to be the one whose imaginary
+part lies in the range from - (exclusive) to (inclusive).
+log 0 is undefined.
+With log defined this way, the values of sin-1 z, cos-1 z,
+and tan-1 z are according to the following formulæ:
+
+
+
+
+The above specification follows [27], which in turn
+cites [19]; refer to these sources for more detailed
+discussion of branch cuts, boundary conditions, and implementation of
+these functions. When it is possible these procedures produce a real
+result from a real argument.
+
+
+
+
+
+
+
+Returns the principal square root of z. The result will have
+either positive real part, or zero real part and non-negative imaginary
+part.
+
+
+
+
+Returns z1 raised to the power z2. For z1 0
+
+0z is 1 if z = 0 and 0 otherwise.
+
+
+
+
+
+
+These procedures are part of every implementation that supports
+general
+complex numbers. Suppose x1, x2, x3, and x4 are
+real numbers and z is a complex number such that
+
+Then
+ (make-rectangular x1 x2) ===> z
+where - < xangle < with xangle = x4 + 2 n
+for some integer n.
+
+
+
+
+
+
+
+Exact->inexact returns an inexact representation of z.
+The value returned is the
+inexact number that is numerically closest to the argument.
+If an exact argument has no reasonably close inexact equivalent,
+then a violation of an implementation restriction may be reported.
+
+Inexact->exact returns an exact representation of
+z. The value returned is the exact number that is numerically
+closest to the argument.
+If an inexact argument has no reasonably close exact equivalent,
+then a violation of an implementation restriction may be reported.
+
+
+These procedures implement the natural one-to-one correspondence between
+exact and inexact integers throughout an
+implementation-dependent range. See section 6.2.3.
+
+
+
+
+
+
+
+Radix must be an exact integer, either 2, 8, 10, or 16. If omitted,
+radix defaults to 10.
+The procedure number->string takes a
+number and a radix and returns as a string an external representation of
+the given number in the given radix such that
+ (let ((number number)
+is true. It is an error if no possible result makes this expression true.
+
+If z is inexact, the radix is 10, and the above expression
+can be satisfied by a result that contains a decimal point,
+then the result contains a decimal point and is expressed using the
+minimum number of digits (exclusive of exponent and trailing
+zeroes) needed to make the above expression
+true [3, 5];
+otherwise the format of the result is unspecified.
+
+The result returned by number->string
+never contains an explicit radix prefix.
+
+
+
+
+
+
+
+
+
+
+Returns a number of the maximally precise representation expressed by the
+given string. Radix must be an exact integer, either 2, 8, 10,
+or 16. If supplied, radix is a default radix that may be overridden
+by an explicit radix prefix in string (e.g. "#o177"). If radix
+is not supplied, then the default radix is 10. If string is not
+a syntactically valid notation for a number, then string->number
+returns #f.
+
+ (string->number "100") ===> 100
+
+
+
+
+
+This section describes operations on some of Scheme's non-numeric data types:
+booleans, pairs, lists, symbols, characters, strings and vectors.
+
+
+
+The standard boolean objects for true and false are written as
+#t and #f. What really
+matters, though, are the objects that the Scheme conditional expressions
+(if, cond, and, or, do) treat as
+true or false. The phrase ``a true value''
+(or sometimes just ``true'') means any object treated as true by the
+conditional expressions, and the phrase ``a false value'' (or
+``false'') means any object treated as false by the conditional expressions.
+
+Of all the standard Scheme values, only #f
+counts as false in conditional expressions.
+Except for #f,
+all standard Scheme values, including #t,
+pairs, the empty list, symbols, numbers, strings, vectors, and procedures,
+count as true.
+
+
+
+
+
+Boolean constants evaluate to themselves, so they do not need to be quoted
+in programs.
+
+ #t ===> #t
+
+
+
+Not returns #t if obj is false, and returns
+#f otherwise.
+
+ (not #t) ===> #f
+
+
+
+
+
+Boolean? returns #t if obj is either #t or
+#f and returns #f otherwise.
+
+ (boolean? #f) ===> #t
+
+
+
+
+
+A pair (sometimes called a dotted pair) is a
+record structure with two fields called the car and cdr fields (for
+historical reasons). Pairs are created by the procedure cons.
+The car and cdr fields are accessed by the procedures car and
+cdr. The car and cdr fields are assigned by the procedures
+set-car! and set-cdr!.
+
+Pairs are used primarily to represent lists. A list can
+be defined recursively as either the empty list or a pair whose
+cdr is a list. More precisely, the set of lists is defined as the smallest
+set X such that
+
+
+
+The objects in the car fields of successive pairs of a list are the
+elements of the list. For example, a two-element list is a pair whose car
+is the first element and whose cdr is a pair whose car is the second element
+and whose cdr is the empty list. The length of a list is the number of
+elements, which is the same as the number of pairs.
+
+The empty list is a special object of its own type
+(it is not a pair); it has no elements and its length is zero.
+
+
+
+The most general notation (external representation) for Scheme pairs is
+the ``dotted'' notation (c1 . c2) where
+c1 is the value of the car field and c2 is the value of the
+cdr field. For example (4 . 5) is a pair whose car is 4 and whose
+cdr is 5. Note that (4 . 5) is the external representation of a
+pair, not an expression that evaluates to a pair.
+
+A more streamlined notation can be used for lists: the elements of the
+list are simply enclosed in parentheses and separated by spaces. The
+empty list is written () . For example,
+
+ (a b c d e)
+
+and
+
+ (a . (b . (c . (d . (e . ())))))
+
+are equivalent notations for a list of symbols.
+
+A chain of pairs not ending in the empty list is called an
+improper list. Note that an improper list is not a list.
+The list and dotted notations can be combined to represent
+improper lists:
+
+ (a b c . d)
+
+is equivalent to
+
+ (a . (b . (c . d)))
+
+Whether a given pair is a list depends upon what is stored in the cdr
+field. When the set-cdr! procedure is used, an object can be a
+list one moment and not the next:
+
+ (define x (list 'a 'b 'c))
+
+
+Within literal expressions and representations of objects read by the
+read procedure, the forms '<datum>,
+`<datum>, ,<datum>, and
+,@<datum> denote two-element lists whose first elements are
+the symbols quote, quasiquote, unquote, and
+unquote-splicing, respectively. The second element in each case
+is <datum>. This convention is supported so that arbitrary Scheme
+programs may be represented as lists. That is, according to Scheme's grammar, every
+<expression> is also a <datum> (see section 7.1.2).
+Among other things, this permits the use of the read procedure to
+parse Scheme programs. See section 3.3.
+
+
+
+Pair? returns #t if obj is a pair, and otherwise
+returns #f.
+
+ (pair? '(a . b)) ===> #t
+
+
+
+
+Returns a newly allocated pair whose car is obj1 and whose cdr is
+obj2. The pair is guaranteed to be different (in the sense of
+eqv?) from every existing object.
+
+ (cons 'a '()) ===> (a)
+
+
+
+
+
+Returns the contents of the car field of pair. Note that it is an
+error to take the car of the empty list.
+
+ (car '(a b c)) ===> a
+
+
+
+
+
+
+Returns the contents of the cdr field of pair.
+Note that it is an error to take the cdr of the empty list.
+
+ (cdr '((a) b c d)) ===> (b c d)
+
+
+
+
+
+
+Stores obj in the car field of pair.
+The value returned by set-car! is unspecified.
+ (define (f) (list 'not-a-constant-list))
+
+
+
+
+
+
+Stores obj in the cdr field of pair.
+The value returned by set-cdr! is unspecified.
+
+
+
+
+
+
+These procedures are compositions of car and cdr, where
+for example caddr could be defined by
+
+ (define caddr (lambda (x) (car (cdr (cdr x))))).
+
+Arbitrary compositions, up to four deep, are provided. There are
+twenty-eight of these procedures in all.
+
+
+
+
+
+Returns #t if obj is the empty list,
+otherwise returns #f.
+
+
+
+
+
+
+Returns #t if obj is a list, otherwise returns #f.
+By definition, all lists have finite length and are terminated by
+the empty list.
+
+ (list? '(a b c)) ===> #t
+
+
+
+
+Returns a newly allocated list of its arguments.
+
+ (list 'a (+ 3 4) 'c) ===> (a 7 c)
+
+
+
+
+
+Returns the length of list.
+
+ (length '(a b c)) ===> 3
+
+
+
+
+
+Returns a list consisting of the elements of the first list
+followed by the elements of the other lists.
+
+ (append '(x) '(y)) ===> (x y)
+
+The resulting list is always newly allocated, except that it shares
+structure with the last list argument. The last argument may
+actually be any object; an improper list results if the last argument is not a
+proper list.
+
+ (append '(a b) '(c . d)) ===> (a b c . d)
+
+
+
+
+
+Returns a newly allocated list consisting of the elements of list
+in reverse order.
+
+ (reverse '(a b c)) ===> (c b a)
+
+
+
+
+Returns the sublist of list obtained by omitting the first k
+elements. It is an error if list has fewer than k elements.
+List-tail could be defined by
+
+ (define list-tail
+
+
+
+
+Returns the kth element of list. (This is the same
+as the car of (list-tail list k).)
+It is an error if list has fewer than k elements.
+
+ (list-ref '(a b c d) 2) ===> c
+
+
+
+
+
+
+These procedures return the first sublist of list whose car is
+obj, where the sublists of list are the non-empty lists
+returned by (list-tail list k) for k less
+than the length of list. If
+obj does not occur in list, then #f (not the empty list) is
+returned. Memq uses eq? to compare obj with the elements of
+list, while memv uses eqv? and member uses equal?.
+
+ (memq 'a '(a b c)) ===> (a b c)
+
+
+
+
+
+Alist (for ``association list'') must be a list of
+pairs. These procedures find the first pair in alist whose car field is obj,
+and returns that pair. If no pair in alist has obj as its
+car, then #f (not the empty list) is returned. Assq uses
+eq? to compare obj with the car fields of the pairs in alist,
+while assv uses eqv? and assoc uses equal?.
+
+ (define e '((a 1) (b 2) (c 3)))
+
+
+
+
+
+Symbols are objects whose usefulness rests on the fact that two
+symbols are identical (in the sense of eqv?) if and only if their
+names are spelled the same way. This is exactly the property needed to
+represent identifiers in programs, and so most
+implementations of Scheme use them internally for that purpose. Symbols
+are useful for many other applications; for instance, they may be used
+the way enumerated values are used in Pascal.
+
+The rules for writing a symbol are exactly the same as the rules for
+writing an identifier; see sections 2.1
+and 7.1.1.
+
+It is guaranteed that any symbol that has been returned as part of
+a literal expression, or read using the read procedure, and
+subsequently written out using the write procedure, will read back
+in as the identical symbol (in the sense of eqv?). The
+string->symbol procedure, however, can create symbols for
+which this write/read invariance may not hold because their names
+contain special characters or letters in the non-standard case.
+
+
+
+Some implementations also have ``uninterned symbols'', which
+defeat write/read invariance even in implementations with slashification,
+and also generate exceptions to the rule that two symbols are the same
+if and only if their names are spelled the same.
+
+
+
+
+Returns #t if obj is a symbol, otherwise returns #f.
+
+ (symbol? 'foo) ===> #t
+
+
+
+
+Returns the name of symbol as a string. If the symbol was part of
+an object returned as the value of a literal expression
+(section 4.1.2) or by a call to the read procedure,
+and its name contains alphabetic characters, then the string returned
+will contain characters in the implementation's preferred standard
+case -- some implementations will prefer upper case, others lower case.
+If the symbol was returned by string->symbol, the case of
+characters in the string returned will be the same as the case in the
+string that was passed to string->symbol. It is an error
+to apply mutation procedures like string-set! to strings returned
+by this procedure.
+
+The following examples assume that the implementation's standard case is
+lower case:
+
+ (symbol->string 'flying-fish)
+
+
+
+
+Returns the symbol whose name is string. This procedure can
+create symbols with names containing special characters or letters in
+the non-standard case, but it is usually a bad idea to create such
+symbols because in some implementations of Scheme they cannot be read as
+themselves. See symbol->string.
+
+The following examples assume that the implementation's standard case is
+lower case:
+
+ (eq? 'mISSISSIppi 'mississippi)
+
+
+
+
+
+Characters are objects that represent printed characters such as
+letters and digits.
+Characters are written using the notation #\<character>
+or #\<character name>.
+For example:
+
+
+
+Case is significant in #\<character>, but not in
+#\<character name>. If <character> in
+#\<character> is alphabetic, then the character
+following <character> must be a delimiter character such as a
+space or parenthesis. This rule resolves the ambiguous case where, for
+example, the sequence of characters ``#\space''
+could be taken to be either a representation of the space character or a
+representation of the character ``#\s'' followed
+by a representation of the symbol ``pace.''
+
+
+Characters written in the #\ notation are self-evaluating.
+That is, they do not have to be quoted in programs.
+
+Some of the procedures that operate on characters ignore the
+difference between upper case and lower case. The procedures that
+ignore case have ``-ci'' (for ``case
+insensitive'') embedded in their names.
+
+
+
+Returns #t if obj is a character, otherwise returns #f.
+
+
+
+
+
+
+
+These procedures impose a total ordering on the set of characters. It
+is guaranteed that under this ordering:
+
+
+
+Some implementations may generalize these procedures to take more than
+two arguments, as with the corresponding numerical predicates.
+
+
+
+
+
+
+These procedures are similar to char=? et cetera, but they treat
+upper case and lower case letters as the same. For example, (char-ci=? #\A #\a) returns #t. Some
+implementations may generalize these procedures to take more than two
+arguments, as with the corresponding numerical predicates.
+
+
+
+
+
+These procedures return #t if their arguments are alphabetic,
+numeric, whitespace, upper case, or lower case characters, respectively,
+otherwise they return #f. The following remarks, which are specific to
+the ASCII character set, are intended only as a guide: The alphabetic characters
+are the 52 upper and lower case letters. The numeric characters are the
+ten decimal digits. The whitespace characters are space, tab, line
+feed, form feed, and carriage return.
+
+
+
+
+
+
+Given a character, char->integer returns an exact integer
+representation of the character. Given an exact integer that is the image of
+a character under char->integer, integer->char
+returns that character. These procedures implement order-preserving isomorphisms
+between the set of characters under the char<=? ordering and some
+subset of the integers under the <= ordering. That is, if
+
+ (char<=? a b) ===> #t and (<= x y) ===> #t
+
+and x and y are in the domain of
+integer->char, then
+
+ (<= (char->integer a)
+
+
+
+
+
+
+These procedures return a character char2 such that (char-ci=? char char2). In addition, if char is
+alphabetic, then the result of char-upcase is upper case and the
+result of char-downcase is lower case.
+
+
+
+
+
+Strings are sequences of characters.
+Strings are written as sequences of characters enclosed within doublequotes
+("). A doublequote can be written inside a string only by escaping
+it with a backslash (\), as in
+
+ "The word \"recursion\" has many meanings."
+
+A backslash can be written inside a string only by escaping it with another
+backslash. Scheme does not specify the effect of a backslash within a
+string that is not followed by a doublequote or backslash.
+
+A string constant may continue from one line to the next, but
+the exact contents of such a string are unspecified.
+
+The length of a string is the number of characters that it
+contains. This number is an exact, non-negative integer that is fixed when the
+string is created. The valid indexes of a string are the
+exact non-negative integers less than the length of the string. The first
+character of a string has index 0, the second has index 1, and so on.
+
+In phrases such as ``the characters of string beginning with
+index start and ending with index end,'' it is understood
+that the index start is inclusive and the index end is
+exclusive. Thus if start and end are the same index, a null
+substring is referred to, and if start is zero and end is
+the length of string, then the entire string is referred to.
+
+Some of the procedures that operate on strings ignore the
+difference between upper and lower case. The versions that ignore case
+have ``-ci'' (for ``case insensitive'') embedded in their
+names.
+
+
+
+Returns #t if obj is a string, otherwise returns #f.
+
+
+
+
+Make-string returns a newly allocated string of
+length k. If char is given, then all elements of the string
+are initialized to char, otherwise the contents of the
+string are unspecified.
+
+
+
+
+
+Returns a newly allocated string composed of the arguments.
+
+
+
+
+
+Returns the number of characters in the given string.
+
+
+
+
+k must be a valid index of string.
+String-ref returns character k of string using zero-origin indexing.
+
+
+
+
+k must be a valid index of string.
+String-set! stores char in element k of string
+and returns an unspecified value.
+ (define (f) (make-string 3 #\*))
+
+
+
+
+
+Returns #t if the two strings are the same length and contain the same
+characters in the same positions, otherwise returns #f.
+String-ci=? treats
+upper and lower case letters as though they were the same character, but
+string=? treats upper and lower case as distinct characters.
+
+
+
+
+
+These procedures are the lexicographic extensions to strings of the
+corresponding orderings on characters. For example, string<? is
+the lexicographic ordering on strings induced by the ordering
+char<? on characters. If two strings differ in length but
+are the same up to the length of the shorter string, the shorter string
+is considered to be lexicographically less than the longer string.
+
+Implementations may generalize these and the string=? and
+string-ci=? procedures to take more than two arguments, as with
+the corresponding numerical predicates.
+
+
+
+
+
+String must be a string, and start and end
+must be exact integers satisfying
+
+Substring returns a newly allocated string formed from the characters of
+string beginning with index start (inclusive) and ending with index
+end (exclusive).
+
+
+
+
+Returns a newly allocated string whose characters form the concatenation of the
+given strings.
+
+
+
+
+
+String->list returns a newly allocated list of the
+characters that make up the given string. List->string
+returns a newly allocated string formed from the characters in the list
+list, which must be a list of characters. String->list
+and list->string are
+inverses so far as equal? is concerned.
+
+
+
+
+
+Returns a newly allocated copy of the given string.
+
+
+
+
+
+Stores char in every element of the given string and returns an
+unspecified value.
+
+
+
+
+Vectors are heterogenous structures whose elements are indexed
+by integers. A vector typically occupies less space than a list
+of the same length, and the average time required to access a randomly
+chosen element is typically less for the vector than for the list.
+
+The length of a vector is the number of elements that it
+contains. This number is a non-negative integer that is fixed when the
+vector is created. The valid indexes of a
+vector are the exact non-negative integers less than the length of the
+vector. The first element in a vector is indexed by zero, and the last
+element is indexed by one less than the length of the vector.
+
+Vectors are written using the notation #(obj ...).
+For example, a vector of length 3 containing the number zero in element
+0, the list (2 2 2 2) in element 1, and the string "Anna" in
+element 2 can be written as following:
+
+ #(0 (2 2 2 2) "Anna")
+
+Note that this is the external representation of a vector, not an
+expression evaluating to a vector. Like list constants, vector
+constants must be quoted:
+
+ '#(0 (2 2 2 2) "Anna")
+
+
+
+
+
+Returns #t if obj is a vector, otherwise returns #f.
+
+
+
+
+Returns a newly allocated vector of k elements. If a second
+argument is given, then each element is initialized to fill.
+Otherwise the initial contents of each element is unspecified.
+
+
+
+
+
+Returns a newly allocated vector whose elements contain the given
+arguments. Analogous to list.
+
+ (vector 'a 'b 'c) ===> #(a b c)
+
+
+
+
+Returns the number of elements in vector as an exact integer.
+
+
+
+
+k must be a valid index of vector.
+Vector-ref returns the contents of element k of
+vector.
+
+ (vector-ref '#(1 1 2 3 5 8 13 21)
+
+
+
+
+k must be a valid index of vector.
+Vector-set! stores obj in element k of vector.
+The value returned by vector-set! is unspecified.
+ (let ((vec (vector 0 '(2 2 2 2) "Anna")))
+
+
+
+
+Vector->list returns a newly allocated list of the objects contained
+in the elements of vector. List->vector returns a newly
+created vector initialized to the elements of the list list.
+
+ (vector->list '#(dah dah didah))
+
+
+
+
+Stores fill in every element of vector.
+The value returned by vector-fill! is unspecified.
+
+
+
+
+
+This chapter describes various primitive procedures which control the
+flow of program execution in special ways.
+The procedure? predicate is also described here.
+
+
+
+
+
+Returns #t if obj is a procedure, otherwise returns #f.
+
+ (procedure? car) ===> #t
+
+
+
+
+
+Proc must be a procedure and args must be a list.
+Calls proc with the elements of the list
+(append (list arg1 ...) args) as the actual
+arguments.
+
+ (apply + (list 3 4)) ===> 7
+
+
+
+
+The lists must be lists, and proc must be a
+procedure taking as many arguments as there are lists
+and returning a single value. If more
+than one list is given, then they must all be the same length.
+Map applies proc element-wise to the elements of the
+lists and returns a list of the results, in order.
+The dynamic order in which proc is applied to the elements of the
+lists is unspecified.
+
+ (map cadr '((a b) (d e) (g h)))
+
+
+
+
+
+The arguments to for-each are like the arguments to map, but
+for-each calls proc for its side effects rather than for its
+values. Unlike map, for-each is guaranteed to call proc on
+the elements of the lists in order from the first element(s) to the
+last, and the value returned by for-each is unspecified.
+
+ (let ((v (make-vector 5)))
+
+
+
+
+
+Forces the value of promise (see delay,
+section 4.2.5). If no value has been computed for
+the promise, then a value is computed and returned. The value of the
+promise is cached (or ``memoized'') so that if it is forced a second
+time, the previously computed value is returned.
+
+ (force (delay (+ 1 2))) ===> 3
+
+Force and delay are mainly intended for programs written in
+functional style. The following examples should not be considered to
+illustrate good programming style, but they illustrate the property that
+only one value is computed for a promise, no matter how many times it is
+forced.
+
+ (define count 0)
+
+Here is a possible implementation of delay and force.
+Promises are implemented here as procedures of no arguments,
+and force simply calls its argument:
+
+ (define force
+
+We define the expression
+
+ (delay <expression>)
+
+to have the same meaning as the procedure call
+
+ (make-promise (lambda () <expression>))
+
+as follows
+
+ (define-syntax delay
+
+where make-promise is defined as follows:
+
+
+ (define make-promise
+
+
+
+Various extensions to this semantics of delay and force
+are supported in some implementations:
+
+
+
+
+
+ (eqv? (delay 1) 1) ===> unspecified
+
+
+
+ (+ (delay (* 3 7)) 13) ===> 34
+
+
+
+
+
+ Proc must be a procedure of one
+argument. The procedure call-with-current-continuation packages
+up the current continuation (see the rationale below) as an ``escape
+procedure'' and passes it as an argument to
+proc. The escape procedure is a Scheme procedure that, if it is
+later called, will abandon whatever continuation is in effect at that later
+time and will instead use the continuation that was in effect
+when the escape procedure was created. Calling the escape procedure
+may cause the invocation of before and after thunks installed using
+dynamic-wind.
+
+The escape procedure accepts the same number of arguments as the continuation to
+the original call to call-with-current-continuation.
+Except for continuations created by the call-with-values
+procedure, all continuations take exactly one value. The
+effect of passing no value or more than one value to continuations
+that were not created by call-with-values is unspecified.
+
+The escape procedure that is passed to proc has
+unlimited extent just like any other procedure in Scheme. It may be stored
+in variables or data structures and may be called as many times as desired.
+
+The following examples show only the most common ways in which
+call-with-current-continuation is used. If all real uses were as
+simple as these examples, there would be no need for a procedure with
+the power of call-with-current-continuation.
+
+ (call-with-current-continuation
+
+
+
+A common use of call-with-current-continuation is for
+structured, non-local exits from loops or procedure bodies, but in fact
+call-with-current-continuation is extremely useful for implementing a
+wide variety of advanced control structures.
+
+Whenever a Scheme expression is evaluated there is a
+continuation wanting the result of the expression. The continuation
+represents an entire (default) future for the computation. If the expression is
+evaluated at top level, for example, then the continuation might take the
+result, print it on the screen, prompt for the next input, evaluate it, and
+so on forever. Most of the time the continuation includes actions
+specified by user code, as in a continuation that will take the result,
+multiply it by the value stored in a local variable, add seven, and give
+the answer to the top level continuation to be printed. Normally these
+ubiquitous continuations are hidden behind the scenes and programmers do not
+think much about them. On rare occasions, however, a programmer may
+need to deal with continuations explicitly.
+Call-with-current-continuation allows Scheme programmers to do
+that by creating a procedure that acts just like the current
+continuation.
+
+Most programming languages incorporate one or more special-purpose
+escape constructs with names like exit, return, or
+even goto. In 1965, however, Peter Landin [16]
+invented a general purpose escape operator called the J-operator. John
+Reynolds [24] described a simpler but equally powerful
+construct in 1972. The catch special form described by Sussman
+and Steele in the 1975 report on Scheme is exactly the same as
+Reynolds's construct, though its name came from a less general construct
+in MacLisp. Several Scheme implementors noticed that the full power of the
+catch construct could be provided by a procedure instead of by a
+special syntactic construct, and the name
+call-with-current-continuation was coined in 1982. This name is
+descriptive, but opinions differ on the merits of such a long name, and
+some people use the name call/cc instead.
+
+
+
+
+
+
+Delivers all of its arguments to its continuation.
+Except for continuations created by the call-with-values
+procedure, all continuations take exactly one value.
+Values might be defined as follows:
+ (define (values . things)
+
+
+
+
+
+Calls its producer argument with no values and
+a continuation that, when passed some values, calls the
+consumer procedure with those values as arguments.
+The continuation for the call to consumer is the
+continuation of the call to call-with-values.
+
+ (call-with-values (lambda () (values 4 5))
+
+
+
+
+
+Calls thunk without arguments, returning the result(s) of this call.
+Before and after are called, also without arguments, as required
+by the following rules (note that in the absence of calls to continuations
+captured using call-with-current-continuation the three arguments are
+called once each, in order). Before is called whenever execution
+enters the dynamic extent of the call to thunk and after is called
+whenever it exits that dynamic extent. The dynamic extent of a procedure
+call is the period between when the call is initiated and when it
+returns. In Scheme, because of call-with-current-continuation, the
+dynamic extent of a call may not be a single, connected time period.
+It is defined as follows:
+
+
+
+
+
+
+
+
+If a second call to dynamic-wind occurs within the dynamic extent of the
+call to thunk and then a continuation is invoked in such a way that the
+afters from these two invocations of dynamic-wind are both to be
+called, then the after associated with the second (inner) call to
+dynamic-wind is called first.
+
+If a second call to dynamic-wind occurs within the dynamic extent of the
+call to thunk and then a continuation is invoked in such a way that the
+befores from these two invocations of dynamic-wind are both to be
+called, then the before associated with the first (outer) call to
+dynamic-wind is called first.
+
+If invoking a continuation requires calling the before from one call
+to dynamic-wind and the after from another, then the after
+is called first.
+
+The effect of using a captured continuation to enter or exit the dynamic
+extent of a call to before or after is undefined.
+
+ (let ((path '())
+
+
+
+
+Evaluates expression in the specified environment and returns its value.
+Expression must be a valid Scheme expression represented as data,
+and environment-specifier must be a value returned by one of the
+three procedures described below.
+Implementations may extend eval to allow non-expression programs
+(definitions) as the first argument and to allow other
+values as environments, with the restriction that eval is not
+allowed to create new bindings in the environments associated with
+null-environment or scheme-report-environment.
+
+ (eval '(* 7 3) (scheme-report-environment 5))
+
+
+
+
+
+Version must be the exact integer 5,
+corresponding to this revision of the Scheme report (the
+Revised5 Report on Scheme).
+Scheme-report-environment returns a specifier for an
+environment that is empty except for all bindings defined in
+this report that are either required or both optional and
+supported by the implementation. Null-environment returns
+a specifier for an environment that is empty except for the
+(syntactic) bindings for all syntactic keywords defined in
+this report that are either required or both optional and
+supported by the implementation.
+
+Other values of version can be used to specify environments
+matching past revisions of this report, but their support is not
+required. An implementation will signal an error if version
+is neither 5 nor another value supported by
+the implementation.
+
+The effect of assigning (through the use of eval) a variable
+bound in a scheme-report-environment
+(for example car) is unspecified. Thus the environments specified
+by scheme-report-environment may be immutable.
+
+
+
+
+
+This procedure returns a specifier for the environment that
+contains implementation-defined bindings, typically a superset of
+those listed in the report. The intent is that this procedure
+will return the environment in which the implementation would evaluate
+expressions dynamically typed by the user.
+
+
+
+
+
+Ports represent input and output devices. To Scheme, an input port is a
+Scheme object that can deliver characters upon command, while an output port
+is a Scheme object that can accept characters.
+
+
+
+
+
+String should be a string naming a file, and
+proc should be a procedure that accepts one argument.
+For call-with-input-file,
+the file should already exist; for
+call-with-output-file,
+the effect is unspecified if the file
+already exists. These procedures call proc with one argument: the
+port obtained by opening the named file for input or output. If the
+file cannot be opened, an error is signalled. If proc returns,
+then the port is closed automatically and the value(s) yielded by the
+proc is(are) returned. If proc does not return, then
+the port will not be closed automatically unless it is possible to
+prove that the port will never again be used for a read or write
+operation.
+
+
+
+
+
+Returns #t if obj is an input port or output port
+respectively, otherwise returns #f.
+
+
+
+
+
+
+
+Returns the current default input or output port.
+
+
+
+
+
+String should be a string naming a file, and
+proc should be a procedure of no arguments.
+For with-input-from-file,
+the file should already exist; for
+with-output-to-file,
+the effect is unspecified if the file
+already exists.
+The file is opened for input or output, an input or output port
+connected to it is made the default value returned by
+current-input-port or current-output-port
+(and is used by (read), (write obj), and so forth),
+and the
+thunk is called with no arguments. When the thunk returns,
+the port is closed and the previous default is restored.
+With-input-from-file and with-output-to-file return(s) the
+value(s) yielded by thunk.
+If an escape procedure
+is used to escape from the continuation of these procedures, their
+behavior is implementation dependent.
+
+
+
+
+
+
+
+
+
+Takes a string naming an existing file and returns an input port capable of
+delivering characters from the file. If the file cannot be opened, an error is
+signalled.
+
+
+
+
+
+Takes a string naming an output file to be created and returns an output
+port capable of writing characters to a new file by that name. If the file
+cannot be opened, an error is signalled. If a file with the given name
+already exists, the effect is unspecified.
+
+
+
+
+
+Closes the file associated with port, rendering the port
+incapable of delivering or accepting characters.
+These routines have no effect if the file has already been closed.
+The value returned is unspecified.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Read converts external representations of Scheme objects into the
+objects themselves. That is, it is a parser for the nonterminal
+<datum> (see sections 7.1.2 and
+6.3.2). Read returns the next
+object parsable from the given input port, updating port to point to
+the first character past the end of the external representation of the object.
+
+If an end of file is encountered in the input before any
+characters are found that can begin an object, then an end of file
+object is returned. The port remains open, and further attempts
+to read will also return an end of file object. If an end of file is
+encountered after the beginning of an object's external representation,
+but the external representation is incomplete and therefore not parsable,
+an error is signalled.
+
+The port argument may be omitted, in which case it defaults to the
+value returned by current-input-port. It is an error to read from
+a closed port.
+
+
+
+
+Returns the next character available from the input port, updating
+the port to point to the following character. If no more characters
+are available, an end of file object is returned. Port may be
+omitted, in which case it defaults to the value returned by current-input-port.
+
+
+
+
+
+Returns the next character available from the input port,
+without updating
+the port to point to the following character. If no more characters
+are available, an end of file object is returned. Port may be
+omitted, in which case it defaults to the value returned by current-input-port.
+
+
+
+
+
+
+
+Returns #t if obj is an end of file object, otherwise returns
+#f. The precise set of end of file objects will vary among
+implementations, but in any case no end of file object will ever be an object
+that can be read in using read.
+
+
+
+
+
+Returns #t if a character is ready on the input port and
+returns #f otherwise. If char-ready returns #t then
+the next read-char operation on the given port is guaranteed
+not to hang. If the port is at end of file then char-ready?
+returns #t. Port may be omitted, in which case it defaults to
+the value returned by current-input-port.
+
+
+
+
+
+
+
+
+
+
+Writes a written representation of obj to the given port. Strings
+that appear in the written representation are enclosed in doublequotes, and
+within those strings backslash and doublequote characters are
+escaped by backslashes.
+Character objects are written using the #\ notation.
+Write returns an unspecified value. The
+port argument may be omitted, in which case it defaults to the value
+returned by current-output-port.
+
+
+
+
+
+Writes a representation of obj to the given port. Strings
+that appear in the written representation are not enclosed in
+doublequotes, and no characters are escaped within those strings. Character
+objects appear in the representation as if written by write-char
+instead of by write. Display returns an unspecified value.
+The port argument may be omitted, in which case it defaults to the
+value returned by current-output-port.
+
+
+
+
+
+Writes an end of line to port. Exactly how this is done differs
+from one operating system to another. Returns an unspecified value.
+The port argument may be omitted, in which case it defaults to the
+value returned by current-output-port.
+
+
+
+
+
+Writes the character char (not an external representation of the
+character) to the given port and returns an unspecified value. The
+port argument may be omitted, in which case it defaults to the value
+returned by current-output-port.
+
+
+
+Questions of system interface generally fall outside of the domain of this
+report. However, the following operations are important enough to
+deserve description here.
+
+
+
+
+
+Filename should be a string naming an existing file
+containing Scheme source code. The load procedure reads
+expressions and definitions from the file and evaluates them
+sequentially. It is unspecified whether the results of the expressions
+are printed. The load procedure does not affect the values
+returned by current-input-port and current-output-port.
+Load returns an unspecified value.
+
+
+
+
+
+Filename must be a string naming an output file to be
+created. The effect of transcript-on is to open the named file
+for output, and to cause a transcript of subsequent interaction between
+the user and the Scheme system to be written to the file. The
+transcript is ended by a call to transcript-off, which closes the
+transcript file. Only one transcript may be in progress at any time,
+though some implementations may relax this restriction. The values
+returned by these procedures are unspecified.
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/r5rs.html b/www/Documents/Standards/R5RS/HTML/r5rs.html
new file mode 100644
index 0000000..ec29f48
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/r5rs.html
@@ -0,0 +1,341 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/www/Documents/Standards/R5RS/HTML/real-index.html b/www/Documents/Standards/R5RS/HTML/real-index.html
new file mode 120000
index 0000000..f8442d6
--- /dev/null
+++ b/www/Documents/Standards/R5RS/HTML/real-index.html
@@ -0,0 +1 @@
+r5rs.html
\ No newline at end of file
diff --git a/www/Documents/Standards/R5RS/index.shtml b/www/Documents/Standards/R5RS/index.shtml
new file mode 100644
index 0000000..24b6ac1
--- /dev/null
+++ b/www/Documents/Standards/R5RS/index.shtml
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+R5RS is the Revised5 Report on the
+Algorithmic Language Scheme. Thanks to the efforts of
+several volunteers, we provide it in numerous formats.
+
+The master copies are
+available in DVI and
+PostScript.
+You can also get it in
+PDF (thanks to Brad Lucier),
+HTML (thanks to Dorai Sitaram, and Bill Robinson
+ for the frames), and
+CHM (thanks to Jonas Lund)
+formats.
+We also offer a
+tar.gz bundle of the HTML files.
+
+The older report, R4RS, is also available in
+
+Windows HLP format (thanks to Sergei Egorov).
+
+The journal
+Higher-Order and Symbolic
+Computation (formerly Lisp and Symbolic
+Computation, which published archival versions of so many
+excellent papers on or using Scheme) has the document in its
+archive. The formal
+citations are
+
+', [2]
+*
++, [2]
+,, [2]
+,@
+-
+...
+/
+;
+<, [2]
+<=
+=
+=>
+>
+>=
+`
+abs
+acos
+and
+angle
+append
+apply, [2]
+asin
+assoc
+assq
+assv
+atan
+#b
+backquote
+begin
+binding
+binding construct
+boolean?, [2]
+bound
+caar
+cadr
+call
+call by need
+call-with-current-continuation
+call-with-input-file
+call-with-output-file
+call-with-values
+car, [2]
+case
+cdddar
+cddddr
+cdr
+ceiling
+char->integer
+char-alphabetic?
+char-ci<=?
+char-ci<?
+char-ci=?
+char-ci>=?
+char-ci>?
+char-downcase
+char-lower-case?
+char-numeric?
+char-ready?
+char-upcase
+char-upper-case?
+char-whitespace?
+char<=?
+char<?
+char=?
+char>=?
+char>?
+char?, [2]
+close-input-port
+close-output-port
+combination
+comma
+comment
+complex?
+cond
+cons
+constant
+continuation
+cos
+current-input-port
+current-output-port
+#d
+define
+define-syntax
+definition
+delay
+denominator
+display
+do
+dotted pair
+dynamic-wind
+#e
+else, [2]
+empty list, [2],
+[3], [4],
+[5], [6],
+[7]
+eof-object?
+eq?
+equal?
+equivalence predicate
+eqv?, [2]
+error
+escape procedure
+eval
+even?
+exact
+exact->inexact
+exact?
+exactness
+exp
+expt
+#f
+false, [2],
+[3]
+floor
+for-each
+force
+gcd
+hygienic
+#i
+identifier, [2],
+[3]
+if
+imag-part
+immutable
+implementation restriction,
+[2]
+improper list
+inexact
+inexact->exact
+inexact?
+initial environment
+input-port?
+integer->char
+integer?
+interaction-environment
+internal definition
+lambda
+lazy evaluation
+lcm
+length
+let
+let*
+let-syntax
+letrec
+letrec-syntax
+library
+library procedure
+list
+list->string
+list->vector
+list-ref
+list-tail
+list?
+load
+location
+log
+macro
+macro keyword
+macro transformer
+macro use
+magnitude
+make-polar
+make-rectangular
+make-string
+make-vector
+map
+max
+member
+memq
+memv
+min
+modulo
+mutable
+negative?
+newline
+not
+null-environment
+null?
+number
+number->string
+number?, [2]
+numerator
+numerical types
+#o
+object
+odd?
+open-input-file
+open-output-file
+optional
+or
+output-port?
+pair
+pair?, [2]
+peek-char
+port
+port?
+positive?
+predicate
+procedure call
+procedure?, [2]
+promise, [2]
+proper tail recursion
+quasiquote
+quote
+quotient
+rational?
+rationalize
+read
+read-char
+real-part
+real?
+referentially transparent
+region, [2],
+[3], [4],
+[5], [6],
+[7]
+remainder
+reverse
+round
+scheme-report-environment
+set!
+set-car!
+set-cdr!
+setcar
+simplest rational
+sin
+sqrt
+string
+string->list
+string->number
+string->symbol
+string-append
+string-ci<=?
+string-ci<?
+string-ci=?
+string-ci>=?
+string-ci>?
+string-copy
+string-fill!
+string-length
+string-ref
+string-set!
+string<=?
+string<?
+string=?
+string>=?
+string>?
+string?, [2]
+substring
+symbol->string
+symbol?, [2]
+syntactic keyword,
+[2], [3]
+syntax definition
+syntax-rules
+#t
+tail call
+tan
+token
+top level environment,
+[2]
+transcript-off
+transcript-on
+true, [2],
+[3], [4],
+[5]
+truncate
+type
+unbound, [2],
+[3]
+unspecified
+valid indexes,
+[2]
+values
+variable, [2],
+[3]
+vector
+vector->list
+vector-fill!
+vector-length
+vector-ref
+vector-set!
+vector?, [2]
+Whitespace
+with-input-from-file
+with-output-to-file
+write
+write-char
+#x
+zero?
+
+
+ Background
+ Acknowledgements
+
+ 1.1 Semantics
+ 1.2 Syntax
+ 1.3 Notation and terminology
+ 1.3.1 Primitive, library, and optional features
+ 1.3.2 Error situations and unspecified behavior
+ 1.3.3 Entry format
+ 1.3.4 Evaluation examples
+ 1.3.5 Naming conventions
+
+ 2.1 Identifiers
+ 2.2 Whitespace and comments
+ 2.3 Other notations
+
+ 3.1 Variables, syntactic keywords, and regions
+ 3.2 Disjointness of types
+ 3.3 External representations
+ 3.4 Storage model
+ 3.5 Proper tail recursion
+
+ 4.1 Primitive expression types
+ 4.1.1 Variable references
+ 4.1.2 Literal expressions
+ 4.1.3 Procedure calls
+ 4.1.4 Procedures
+ 4.1.5 Conditionals
+ 4.1.6 Assignments
+ 4.2 Derived expression types
+ 4.2.1 Conditionals
+ 4.2.2 Binding constructs
+ 4.2.3 Sequencing
+ 4.2.4 Iteration
+ 4.2.5 Delayed evaluation
+ 4.2.6 Quasiquotation
+ 4.3 Macros
+ 4.3.1 Binding constructs for syntactic keywords
+ 4.3.2 Pattern language
+
+ 5.1 Programs
+ 5.2 Definitions
+ 5.2.1 Top level definitions
+ 5.2.2 Internal definitions
+ 5.3 Syntax definitions
+
+ 6.1 Equivalence predicates
+ 6.2 Numbers
+ 6.2.1 Numerical types
+ 6.2.2 Exactness
+ 6.2.3 Implementation restrictions
+ 6.2.4 Syntax of numerical constants
+ 6.2.5 Numerical operations
+ 6.2.6 Numerical input and output
+ 6.3 Other data types
+ 6.3.1 Booleans
+ 6.3.2 Pairs and lists
+ 6.3.3 Symbols
+ 6.3.4 Characters
+ 6.3.5 Strings
+ 6.3.6 Vectors
+ 6.4 Control features
+ 6.5 Eval
+ 6.6 Input and output
+ 6.6.1 Ports
+ 6.6.2 Input
+ 6.6.3 Output
+ 6.6.4 System interface
+
+ 7.1 Formal syntax
+ 7.1.1 Lexical structure
+ 7.1.2 External representations
+ 7.1.3 Expressions
+ 7.1.4 Quasiquotations
+ 7.1.5 Transformers
+ 7.1.6 Programs and definitions
+ 7.2 Formal semantics
+ 7.2.1 Abstract syntax
+ 7.2.2 Domain equations
+ 7.2.3 Semantic functions
+ 7.2.4 Auxiliary functions
+ 7.3 Derived expression types
+
+ Language changes
+
+
+
+
+
Background
Acknowledgements
+
1.1 Semantics
1.2 Syntax
1.3 Notation and terminology
1.3.1 Primitive, library, and optional features
1.3.2 Error situations and unspecified behavior
1.3.3 Entry format
+
+
+
+
+obj any object
+list, list1, ... listj, ... list (see section 6.3.2)
+z, z1, ... zj, ... complex number
+x, x1, ... xj, ... real number
+y, y1, ... yj, ... real number
+q, q1, ... qj, ... rational number
+n, n1, ... nj, ... integer
+k, k1, ... kj, ... exact non-negative integer 1.3.4 Evaluation examples
1.3.5 Naming conventions
+
2.1 Identifiers
+list->vector soup
++ V17a
+<=? a34kTMNs
+the-word-recursion-has-many-meanings&
* + - . / : < = > ? @ ^
_
~
+
2.2 Whitespace and comments
+;;; of a non-negative integer.
+(define fact
+ (lambda (n)
+ (if (= n 0)
+ 1 ;Base case: return 1
+ (* n (fact (- n 1))))))2.3 Other notations
[ ] { } |
+Left and right square brackets and curly braces and vertical bar
+are reserved for possible future extensions to the language.
+
3.1 Variables, syntactic keywords, and regions
3.2 Disjointness of types
+symbol? number?
+char? string?
+vector? port?
+procedure?3.3 External representations
3.4 Storage model
3.5 Proper tail recursion
Rationale:
+
+ <definition>* <expression>* <tail expression>)
+
+(if <expression> <tail expression>)
+
+(cond <cond clause>+)
+(cond <cond clause>* (else <tail sequence>))
+
+(case <expression>
+ <case clause>+)
+(case <expression>
+ <case clause>*
+ (else <tail sequence>))
+
+(and <expression>* <tail expression>)
+(or <expression>* <tail expression>)
+
+(let (<binding spec>*) <tail body>)
+(let <variable> (<binding spec>*) <tail body>)
+(let* (<binding spec>*) <tail body>)
+(letrec (<binding spec>*) <tail body>)
+
+(let-syntax (<syntax spec>*) <tail body>)
+(letrec-syntax (<syntax spec>*) <tail body>)
+
+(begin <tail sequence>)
+
+(do (<iteration spec>*)
+ (<test> <tail sequence>)
+ <expression>*)
+
+where
+
+<cond clause> ---> (<test> <tail sequence>)
+<case clause> ---> ((<datum>*) <tail sequence>)
+
+<tail body> ---> <definition>* <tail sequence>
+<tail sequence> ---> <expression>* <tail expression>
+
+ (if (g)
+ (let ((x (h)))
+ x)
+ (and (g) (f))))
+Note:
+Implementations are allowed, but not required, to
+recognize that some non-tail calls, such as the call to h
+above, can be evaluated as though they were tail calls.
+In the example above, the let expression could be compiled
+as a tail call to h. (The possibility of h returning
+an unexpected number of values can be ignored, because in that
+case the effect of the let is explicitly unspecified and
+implementation-dependent.)
+
+
4.1 Primitive expression types
4.1.1 Variable references
+x ===> 284.1.2 Literal expressions
+(quote #(a b c)) ===> #(a b c)
+(quote (+ 1 2)) ===> (+ 1 2)
+'#(a b c) ===> #(a b c)
+'() ===> ()
+'(+ 1 2) ===> (+ 1 2)
+'(quote a) ===> (quote a)
+''a ===> (quote a)
+"abc" ===> "abc"
+'145932 ===> 145932
+145932 ===> 145932
+'#t ===> #t
+#t ===> #t4.1.3 Procedure calls
+((if #f + *) 3 4) ===> 12Note: In contrast to other dialects of Lisp, the order of
+evaluation is unspecified, and the operator expression and the operand
+expressions are always evaluated with the same evaluation rules.
+
Note:
+Although the order of evaluation is otherwise unspecified, the effect of
+any concurrent evaluation of the operator and operand expressions is
+constrained to be consistent with some sequential order of evaluation.
+The order of evaluation may be chosen differently for each procedure call.
+
Note: In many dialects of Lisp, the empty combination, (), is a legitimate expression. In Scheme, combinations must have at
+least one subexpression, so () is not a syntactically valid
+expression.
+
4.1.4 Procedures
+((lambda (x) (+ x x)) 4) ===> 8
+
+(define reverse-subtract
+ (lambda (x y) (- y x)))
+(reverse-subtract 7 10) ===> 3
+
+(define add4
+ (let ((x 4))
+ (lambda (y) (+ x y))))
+(add4 6) ===> 10
+
+((lambda (x y . z) z)
+ 3 4 5 6) ===> (5 6)4.1.5 Conditionals
+(if (> 2 3) 'yes 'no) ===> no
+(if (> 3 2)
+ (- 3 2)
+ (+ 3 2)) ===> 14.1.6 Assignments
+(+ x 1) ===> 3
+(set! x 4) ===> unspecified
+(+ x 1) ===> 54.2 Derived expression types
4.2.1 Conditionals
+ ((< 3 2) 'less)) ===> greater
+(cond ((> 3 3) 'greater)
+ ((< 3 3) 'less)
+ (else 'equal)) ===> equal
+(cond ((assv 'b '((a 1) (b 2))) => cadr)
+ (else #f)) ===> 2
+ ((2 3 5 7) 'prime)
+ ((1 4 6 8 9) 'composite)) ===> composite
+(case (car '(c d))
+ ((a) 'a)
+ ((b) 'b)) ===> unspecified
+(case (car '(c d))
+ ((a e i o u) 'vowel)
+ ((w y) 'semivowel)
+ (else 'consonant)) ===> consonant
+(and (= 2 2) (< 2 1)) ===> #f
+(and 1 2 'c '(f g)) ===> (f g)
+(and) ===> #t
+(or (= 2 2) (< 2 1)) ===> #t
+(or #f #f #f) ===> #f
+(or (memq 'b '(a b c))
+ (/ 3 0)) ===> (b c)4.2.2 Binding constructs
+ (* x y)) ===> 6
+
+(let ((x 2) (y 3))
+ (let ((x 7)
+ (z (+ x y)))
+ (* z x))) ===> 35
+ (let* ((x 7)
+ (z (+ x y)))
+ (* z x))) ===> 70
+ (lambda (n)
+ (if (zero? n)
+ #t
+ (odd? (- n 1)))))
+ (odd?
+ (lambda (n)
+ (if (zero? n)
+ #f
+ (even? (- n 1))))))
+ (even? 88))
+ ===> #t4.2.3 Sequencing
+
+(begin (set! x 5)
+ (+ x 1)) ===> 6
+
+(begin (display "4 plus 1 equals ")
+ (display (+ 4 1))) ===> unspecified
+ and prints 4 plus 1 equals 54.2.4 Iteration
+ (<test> <expression> ...)
+ <command> ...)
+ (i 0 (+ i 1)))
+ ((= i 5) vec)
+ (vector-set! vec i i)) ===> #(0 1 2 3 4)
+
+(let ((x '(1 3 5 7 9)))
+ (do ((x x (cdr x))
+ (sum 0 (+ sum (car x))))
+ ((null? x) sum))) ===> 25
+ (nonneg '())
+ (neg '()))
+ (cond ((null? numbers) (list nonneg neg))
+ ((>= (car numbers) 0)
+ (loop (cdr numbers)
+ (cons (car numbers) nonneg)
+ neg))
+ ((< (car numbers) 0)
+ (loop (cdr numbers)
+ nonneg
+ (cons (car numbers) neg)))))
===> ((6 1 3) (-5 -2))4.2.5 Delayed evaluation
4.2.6 Quasiquotation
+(let ((name 'a)) `(list ,name ',name))
===> (list a (quote a))
+`(a ,(+ 1 2) ,@(map abs '(4 -5 6)) b)
===> (a 3 4 5 6 b)
+`(( foo ,(- 10 3)) ,@(cdr '(c)) . ,(car '(cons)))
===> ((foo 7) . cons)
+`#(10 5 ,(sqrt 4) ,@(map sqrt '(16 9)) 8)
===> #(10 5 2 4 3 8)
===> (a `(b ,(+ 1 2) ,(foo 4 d) e) f)
+(let ((name1 'x)
+ (name2 'y))
+ `(a `(b ,,name1 ,',name2 d) e))
===> (a `(b ,x ,'y d) e)
===> (list 3 4)
+'(quasiquote (list (unquote (+ 1 2)) 4))
===> `(list ,(+ 1 2) 4)
+ i.e., (quasiquote (list (unquote (+ 1 2)) 4))4.3 Macros
+
4.3.1 Binding constructs for syntactic keywords
+ ((when test stmt1 stmt2 ...)
+ (if test
+ (begin stmt1
+ stmt2 ...))))))
+ (let ((if #t))
+ (when if (set! if 'now))
+ if)) ===> now
+
+(let ((x 'outer))
+ (let-syntax ((m (syntax-rules () ((m) x))))
+ (let ((x 'inner))
+ (m)))) ===> outer
+ ((my-or (syntax-rules ()
+ ((my-or) #f)
+ ((my-or e) e)
+ ((my-or e1 e2 ...)
+ (let ((temp e1))
+ (if temp
+ temp
+ (my-or e2 ...)))))))
+ (let ((x #f)
+ (y 7)
+ (temp 8)
+ (let odd?)
+ (if even?))
+ (my-or x
+ (let temp)
+ (if y)
+ y))) ===> 74.3.2 Pattern language
+(<pattern> <pattern> ... . <pattern>)
+(<pattern> ... <pattern> <ellipsis>)
+#(<pattern> ...)
+#(<pattern> ... <pattern> <ellipsis>)
+(<element> <element> ... . <template>)
+#(<element> ...)Rationale:
+The scope of the keyword is determined by the expression or syntax
+definition that binds it to the associated macro transformer.
+If the keyword were a pattern variable or literal
+identifier, then
+the template that follows the pattern would be within its scope
+regardless of whether the keyword were bound by let-syntax
+or by letrec-syntax.
+
+
+ (cond (#t => 'ok))) ===> ok
+ (if #t (begin => 'ok)))
+ (let ((temp #t))
+ (if temp ('ok temp))))
+
5.1 Programs
5.2 Definitions
+ (lambda (<formals>) <body>)).
+ (lambda <formal> <body>)).5.2.1 Top level definitions
+ (lambda (x) (+ x 3)))
+(add3 3) ===> 6
+(define first car)
+(first '(1 2)) ===> 15.2.2 Internal definitions
+ (define foo (lambda (y) (bar x y)))
+ (define bar (lambda (a b) (+ (* a b) a)))
+ (foo (+ x 3))) ===> 45
+ (letrec ((foo (lambda (y) (bar x y)))
+ (bar (lambda (a b) (+ (* a b) a))))
+ (foo (+ x 3))))5.3 Syntax definitions
+
+(begin (define begin list))
+
+(let-syntax
+ ((foo (syntax-rules ()
+ ((foo (proc args ...) body ...)
+ (define proc
+ (lambda (args ...)
+ body ...))))))
+ (let ((x 3))
+ (foo (plus x y) (+ x y))
+ (define foo x)
+ (plus foo x)))
+
+
6.1 Equivalence predicates
+
+ (symbol->string obj2))
+ ===> #tNote:
+This assumes that neither obj1 nor obj2 is an ``uninterned
+symbol'' as alluded to in section 6.3.3. This report does
+not presume to specify the behavior of eqv? on implementation-dependent
+extensions.
+
+
+ (symbol->string obj2))
+ ===> #f
+(eqv? 'a 'b) ===> #f
+(eqv? 2 2) ===> #t
+(eqv? '() '()) ===> #t
+(eqv? 100000000 100000000) ===> #t
+(eqv? (cons 1 2) (cons 1 2)) ===> #f
+(eqv? (lambda () 1)
+ (lambda () 2)) ===> #f
+(eqv? #f 'nil) ===> #f
+(let ((p (lambda (x) x)))
+ (eqv? p p)) ===> #t
+(eqv? '#() '#()) ===> unspecified
+(eqv? (lambda (x) x)
+ (lambda (x) x)) ===> unspecified
+(eqv? (lambda (x) x)
+ (lambda (y) y)) ===> unspecified
+ (lambda ()
+ (let ((n 0))
+ (lambda () (set! n (+ n 1)) n))))
+(let ((g (gen-counter)))
+ (eqv? g g)) ===> #t
+(eqv? (gen-counter) (gen-counter))
+ ===> #f
+(define gen-loser
+ (lambda ()
+ (let ((n 0))
+ (lambda () (set! n (+ n 1)) 27))))
+(let ((g (gen-loser)))
+ (eqv? g g)) ===> #t
+(eqv? (gen-loser) (gen-loser))
+ ===> unspecified
+
+(letrec ((f (lambda () (if (eqv? f g) 'both 'f)))
+ (g (lambda () (if (eqv? f g) 'both 'g))))
+ (eqv? f g))
+ ===> unspecified
+
+(letrec ((f (lambda () (if (eqv? f g) 'f 'both)))
+ (g (lambda () (if (eqv? f g) 'g 'both))))
+ (eqv? f g))
+ ===> #f
+(eqv? "a" "a") ===> unspecified
+(eqv? '(b) (cdr '(a b))) ===> unspecified
+(let ((x '(a)))
+ (eqv? x x)) ===> #tRationale:
+The above definition of eqv? allows implementations latitude in
+their treatment of procedures and literals: implementations are free
+either to detect or to fail to detect that two procedures or two literals
+are equivalent to each other, and can decide whether or not to
+merge representations of equivalent objects by using the same pointer or
+bit pattern to represent both.
+
+(eq? '(a) '(a)) ===> unspecified
+(eq? (list 'a) (list 'a)) ===> #f
+(eq? "a" "a") ===> unspecified
+(eq? "" "") ===> unspecified
+(eq? '() '()) ===> #t
+(eq? 2 2) ===> unspecified
+(eq? #\A #\A) ===> unspecified
+(eq? car car) ===> #t
+(let ((n (+ 2 3)))
+ (eq? n n)) ===> unspecified
+(let ((x '(a)))
+ (eq? x x)) ===> #t
+(let ((x '#()))
+ (eq? x x)) ===> #t
+(let ((p (lambda (x) x)))
+ (eq? p p)) ===> #tRationale: It will usually be possible to implement eq? much
+more efficiently than eqv?, for example, as a simple pointer
+comparison instead of as some more complicated operation. One reason is
+that it may not be possible to compute eqv? of two numbers in
+constant time, whereas eq? implemented as pointer comparison will
+always finish in constant time. Eq? may be used like eqv?
+in applications using procedures to implement objects with state since
+it obeys the same constraints as eqv?.
+
+(equal? '(a) '(a)) ===> #t
+(equal? '(a (b) c)
+ '(a (b) c)) ===> #t
+(equal? "abc" "abc") ===> #t
+(equal? 2 2) ===> #t
+(equal? (make-vector 5 'a)
+ (make-vector 5 'a)) ===> #t
+(equal? (lambda (x) x)
+ (lambda (y) y)) ===> unspecified6.2 Numbers
6.2.1 Numerical types
+ complex
+ real
+ rational
+ integer
+6.2.2 Exactness
6.2.3 Implementation restrictions
+quotient remainder modulo
+max min abs
+numerator denominator gcd
+lcm floor ceiling
+truncate round rationalize
+expt6.2.4 Syntax of numerical constants
+ Round to single --- 3.141593
+0.6L0
+ Extend to long --- .6000000000000006.2.5 Numerical operations
+(complex? 3) ===> #t
+(real? 3) ===> #t
+(real? -2.5+0.0i) ===> #t
+(real? #e1e10) ===> #t
+(rational? 6/10) ===> #t
+(rational? 6/3) ===> #t
+(integer? 3+0i) ===> #t
+(integer? 3.0) ===> #t
+(integer? 8/4) ===> #tNote:
+The behavior of these type predicates on inexact numbers
+is unreliable, since any inaccuracy may affect the result.
+
Note:
+In many implementations the rational? procedure will be the same
+as real?, and the complex? procedure will be the same as
+number?, but unusual implementations may be able to represent
+some irrational numbers exactly or may extend the number system to
+support some kind of non-complex numbers.
+
Note:
+The traditional implementations of these predicates in Lisp-like
+languages are not transitive.
+
Note:
+While it is not an error to compare inexact numbers using these
+predicates, the results may be unreliable because a small inaccuracy
+may affect the result; this is especially true of = and zero?.
+When in doubt, consult a numerical analyst.
+
+(max 3.9 4) ===> 4.0 ; inexactNote:
+If any argument is inexact, then the result will also be inexact (unless
+the procedure can prove that the inaccuracy is not large enough to affect the
+result, which is possible only in unusual implementations). If min or
+max is used to compare numbers of mixed exactness, and the numerical
+value of the result cannot be represented as an inexact number without loss of
+accuracy, then the procedure may report a violation of an implementation
+restriction.
+
+(+ 3) ===> 3
+(+) ===> 0
+(* 4) ===> 4
+(*) ===> 1
+(- 3 4 5) ===> -6
+(- 3) ===> -3
+(/ 3 4 5) ===> 3/20
+(/ 3) ===> 1/3
+
+ (remainder n1 n2) ===> 0
+ (modulo n1 n2) ===> 0
+
+ (remainder n1 n2) ===> nr
+ (modulo n1 n2) ===> nm
+
+ (remainder n1 n2)))
+ ===> #t
+(remainder 13 4) ===> 1
+
+(modulo -13 4) ===> 3
+(remainder -13 4) ===> -1
+
+(modulo 13 -4) ===> -3
+(remainder 13 -4) ===> 1
+
+(modulo -13 -4) ===> -1
+(remainder -13 -4) ===> -1
+
+(remainder -13 -4.0) ===> -1.0 ; inexact
+(gcd) ===> 0
+(lcm 32 -36) ===> 288
+(lcm 32.0 -36) ===> 288.0 ; inexact
+(lcm) ===> 1
+(denominator (/ 6 4)) ===> 2
+(denominator
+ (exact->inexact (/ 6 4))) ===> 2.0Rationale:
+Round rounds to even for consistency with the default rounding
+mode specified by the IEEE floating point standard.
+
Note:
+If the argument to one of these procedures is inexact, then the result
+will also be inexact. If an exact value is needed, the
+result should be passed to the inexact->exact procedure.
+
+(ceiling -4.3) ===> -4.0
+(truncate -4.3) ===> -4.0
+(round -4.3) ===> -4.0
+
+(floor 3.5) ===> 3.0
+(ceiling 3.5) ===> 4.0
+(truncate 3.5) ===> 3.0
+(round 3.5) ===> 4.0 ; inexact
+
+(round 7/2) ===> 4 ; exact
+(round 7) ===> 7
+ (inexact->exact .3) 1/10) ===> 1/3 ; exact
+(rationalize .3 1/10) ===> #i1/3 ; inexactsin-1 z = - i log (i z + (1 - z2)1/2) cos-1 z = / 2 - sin-1 z tan-1 z = (log (1 + i z) - log (1 - i z)) / (2 i) z1z2 = ez2 log z1 z = x1 + x2i
+ = x3 · ei x4
+(make-polar x3 x4) ===> z
+(real-part z) ===> x1
+(imag-part z) ===> x2
+(magnitude z) ===> |x3|
+(angle z) ===> xangle
+Rationale:
+Magnitude is the same as abs for a real argument,
+but abs must be present in all implementations, whereas
+magnitude need only be present in implementations that support
+general complex numbers.
+
6.2.6 Numerical input and output
+ (radix radix))
+ (eqv? number
+ (string->number (number->string number
+ radix)
+ radix)))
+Note:
+The error case can occur only when z is not a complex number
+or is a complex number with a non-rational real or imaginary part.
+
Rationale:
+If z is an inexact number represented using flonums, and
+the radix is 10, then the above expression is normally satisfied by
+a result containing a decimal point. The unspecified case
+allows for infinities, NaNs, and non-flonum representations.
+
+(string->number "100" 16) ===> 256
+(string->number "1e2") ===> 100.0
+(string->number "15##") ===> 1500.0Note:
+The domain of string->number may be restricted by implementations
+in the following ways. String->number is permitted to return
+#f whenever string contains an explicit radix prefix.
+If all numbers supported by an implementation are real, then
+string->number is permitted to return #f whenever
+string uses the polar or rectangular notations for complex
+numbers. If all numbers are integers, then
+string->number may return #f whenever
+the fractional notation is used. If all numbers are exact, then
+string->number may return #f whenever
+an exponent marker or explicit exactness prefix is used, or if
+a # appears in place of a digit. If all inexact
+numbers are integers, then
+string->number may return #f whenever
+a decimal point is used.
+
6.3 Other data types
6.3.1 Booleans
Note:
+Programmers accustomed to other dialects of Lisp should be aware that
+Scheme distinguishes both #f and the empty list
+from the symbol nil.
+
+#f ===> #f
+'#f ===> #f
+(not 3) ===> #f
+(not (list 3)) ===> #f
+(not #f) ===> #t
+(not '()) ===> #f
+(not (list)) ===> #f
+(not 'nil) ===> #f
+(boolean? 0) ===> #f
+(boolean? '()) ===> #f6.3.2 Pairs and lists
+
Note:
+The above definitions imply that all lists have finite length and are
+terminated by the empty list.
+
+(define y x)
+y ===> (a b c)
+(list? y) ===> #t
+(set-cdr! x 4) ===> unspecified
+x ===> (a . 4)
+(eqv? x y) ===> #t
+y ===> (a . 4)
+(list? y) ===> #f
+(set-cdr! x x) ===> unspecified
+(list? x) ===> #f
+(pair? '(a b c)) ===> #t
+(pair? '()) ===> #f
+(pair? '#(a b)) ===> #f
+(cons '(a) '(b c d)) ===> ((a) b c d)
+(cons "a" '(b c)) ===> ("a" b c)
+(cons 'a 3) ===> (a . 3)
+(cons '(a b) 'c) ===> ((a b) . c)
+(car '((a) b c d)) ===> (a)
+(car '(1 . 2)) ===> 1
+(car '()) ===> error
+(cdr '(1 . 2)) ===> 2
+(cdr '()) ===> error
+(define (g) '(constant-list))
+(set-car! (f) 3) ===> unspecified
+(set-car! (g) 3) ===> error
+ (list? '()) ===> #t
+ (list? '(a . b)) ===> #f
+ (let ((x (list 'a)))
+ (set-cdr! x x)
+ (list? x)) ===> #f
+(list) ===> ()
+(length '(a (b) (c d e))) ===> 3
+(length '()) ===> 0
+(append '(a) '(b c d)) ===> (a b c d)
+(append '(a (b)) '((c))) ===> (a (b) (c))
+(append '() 'a) ===> a
+(reverse '(a (b c) d (e (f))))
===> ((e (f)) d (b c) a)
+ (lambda (x k)
+ (if (zero? k)
+ x
+ (list-tail (cdr x) (- k 1)))))
+(list-ref '(a b c d)
+ (inexact->exact (round 1.8)))
===> c
+(memq 'b '(a b c)) ===> (b c)
+(memq 'a '(b c d)) ===> #f
+(memq (list 'a) '(b (a) c)) ===> #f
+(member (list 'a)
+ '(b (a) c)) ===> ((a) c)
+(memq 101 '(100 101 102)) ===> unspecified
+(memv 101 '(100 101 102)) ===> (101 102)
+(assq 'a e) ===> (a 1)
+(assq 'b e) ===> (b 2)
+(assq 'd e) ===> #f
+(assq (list 'a) '(((a)) ((b)) ((c))))
+ ===> #f
+(assoc (list 'a) '(((a)) ((b)) ((c))))
+ ===> ((a))
+(assq 5 '((2 3) (5 7) (11 13)))
+ ===> unspecified
+(assv 5 '((2 3) (5 7) (11 13)))
+ ===> (5 7)Rationale:
+Although they are ordinarily used as predicates,
+memq, memv, member, assq, assv, and assoc do not
+have question marks in their names because they return useful values rather
+than just #t or #f.
+
+6.3.3 Symbols
Note:
+Some implementations of Scheme have a feature known as ``slashification''
+in order to guarantee write/read invariance for all symbols, but
+historically the most important use of this feature has been to
+compensate for the lack of a string data type.
+(symbol? (car '(a b))) ===> #t
+(symbol? "bar") ===> #f
+(symbol? 'nil) ===> #t
+(symbol? '()) ===> #f
+(symbol? #f) ===> #f
+ ===> "flying-fish"
+(symbol->string 'Martin) ===> "martin"
+(symbol->string
+ (string->symbol "Malvina"))
+ ===> "Malvina"
===> #t
+(string->symbol "mISSISSIppi")
===> the symbol with name "mISSISSIppi"
+(eq? 'bitBlt (string->symbol "bitBlt"))
===> #f
+(eq? 'JollyWog
+ (string->symbol
+ (symbol->string 'JollyWog)))
===> #t
+(string=? "K. Harper, M.D."
+ (symbol->string
+ (string->symbol "K. Harper, M.D.")))
===> #t6.3.4 Characters
+
+
+
+
+#\a ; lower case letter
+#\A ; upper case letter
+#\( ; left parenthesis
+#\ ; the space character
+#\space ; the preferred way to write a space
+#\newline ; the newline character
+
+ (char->integer b)) ===> #t
+
+(char<=? (integer->char x)
+ (integer->char y)) ===> #t6.3.5 Strings
+(define (g) "***")
+(string-set! (f) 0 #\?) ===> unspecified
+(string-set! (g) 0 #\?) ===> error
+(string-set! (symbol->string 'immutable)
+ 0
+ #\?) ===> error0 < start < end < (string-length string). 6.3.6 Vectors
===> #(0 (2 2 2 2) "Anna")
+ 5)
===> 8
+(vector-ref '#(1 1 2 3 5 8 13 21)
+ (let ((i (round (* 2 (acos -1)))))
+ (if (inexact? i)
+ (inexact->exact i)
+ i)))
===> 13
+ (vector-set! vec 1 '("Sue" "Sue"))
+ vec)
===> #(0 ("Sue" "Sue") "Anna")
+
+(vector-set! '#(0 1 2) 1 "doe")
===> error ; constant vector
===> (dah dah didah)
+(list->vector '(dididit dah))
===> #(dididit dah)6.4 Control features
+(procedure? 'car) ===> #f
+(procedure? (lambda (x) (* x x)))
+ ===> #t
+(procedure? '(lambda (x) (* x x)))
+ ===> #f
+(call-with-current-continuation procedure?)
+ ===> #t
+
+(define compose
+ (lambda (f g)
+ (lambda args
+ (f (apply g args)))))
+
+((compose sqrt *) 12 75) ===> 30
===> (b e h)
+
+(map (lambda (n) (expt n n))
+ '(1 2 3 4 5))
===> (1 4 27 256 3125)
+
+(map + '(1 2 3) '(4 5 6)) ===> (5 7 9)
+
+(let ((count 0))
+ (map (lambda (ignored)
+ (set! count (+ count 1))
+ count)
+ '(a b))) ===> (1 2) or (2 1)
+
+ (for-each (lambda (i)
+ (vector-set! v i (* i i)))
+ '(0 1 2 3 4))
+ v) ===> #(0 1 4 9 16)
+(let ((p (delay (+ 1 2))))
+ (list (force p) (force p)))
+ ===> (3 3)
+
+(define a-stream
+ (letrec ((next
+ (lambda (n)
+ (cons n (delay (next (+ n 1)))))))
+ (next 0)))
+(define head car)
+(define tail
+ (lambda (stream) (force (cdr stream))))
+
+(head (tail (tail a-stream)))
+ ===> 2
+(define p
+ (delay (begin (set! count (+ count 1))
+ (if (> count x)
+ count
+ (force p)))))
+(define x 5)
+p ===> a promise
+(force p) ===> 6
+p ===> a promise, still
+(begin (set! x 10)
+ (force p)) ===> 6
+ (lambda (object)
+ (object)))
+
+ (syntax-rules ()
+ ((delay expression)
+ (make-promise (lambda () expression))))),
+ (lambda (proc)
+ (let ((result-ready? #f)
+ (result #f))
+ (lambda ()
+ (if result-ready?
+ result
+ (let ((x (proc)))
+ (if result-ready?
+ result
+ (begin (set! result-ready? #t)
+ (set! result x)
+ result))))))))Rationale:
+A promise may refer to its own value, as in the last example above.
+Forcing such a promise may cause the promise to be forced a second time
+before the value of the first force has been computed.
+This complicates the definition of make-promise.
+
+
+(pair? (delay (cons 1 2))) ===> unspecified
+ (lambda (exit)
+ (for-each (lambda (x)
+ (if (negative? x)
+ (exit x)))
+ '(54 0 37 -3 245 19))
+ #t)) ===> -3
+
+(define list-length
+ (lambda (obj)
+ (call-with-current-continuation
+ (lambda (return)
+ (letrec ((r
+ (lambda (obj)
+ (cond ((null? obj) 0)
+ ((pair? obj)
+ (+ (r (cdr obj)) 1))
+ (else (return #f))))))
+ (r obj))))))
+
+(list-length '(1 2 3 4)) ===> 4
+
+(list-length '(a b . c)) ===> #fRationale:
+ (call-with-current-continuation
+ (lambda (cont) (apply cont things))))
+
+ (lambda (a b) b))
+ ===> 5
+
+(call-with-values * -) ===> -1
+
+
+ (c #f))
+ (let ((add (lambda (s)
+ (set! path (cons s path)))))
+ (dynamic-wind
+ (lambda () (add 'connect))
+ (lambda ()
+ (add (call-with-current-continuation
+ (lambda (c0)
+ (set! c c0)
+ 'talk1))))
+ (lambda () (add 'disconnect)))
+ (if (< (length path) 4)
+ (c 'talk2)
+ (reverse path))))
+
===> (connect talk1 disconnect
+ connect talk2 disconnect)
+6.5 Eval
+ ===> 21
+
+(let ((f (eval '(lambda (f x) (f x x))
+ (null-environment 5))))
+ (f + 10))
+ ===> 20
+6.6 Input and output
6.6.1 Ports
Rationale:
+Because Scheme's escape procedures have unlimited extent, it is
+possible to escape from the current continuation but later to escape back in.
+If implementations were permitted to close the port on any escape from the
+current continuation, then it would be impossible to write portable code using
+both call-with-current-continuation and call-with-input-file or
+call-with-output-file.
+
+
+6.6.2 Input
Note:
+The value returned by a call to peek-char is the same as the
+value that would have been returned by a call to read-char with the
+same port. The only difference is that the very next call to
+read-char or peek-char on that port will return the
+value returned by the preceding call to peek-char. In particular, a call
+to peek-char on an interactive port will hang waiting for input
+whenever a call to read-char would have hung.
+
Rationale:
+Char-ready? exists to make it possible for a program to
+accept characters from interactive ports without getting stuck waiting for
+input. Any input editors associated with such ports must ensure that
+characters whose existence has been asserted by char-ready? cannot
+be rubbed out. If char-ready? were to return #f at end of
+file, a port at end of file would be indistinguishable from an interactive
+port that has no ready characters.
+
+6.6.3 Output
Rationale:
+Write is intended
+for producing machine-readable output and display is for producing
+human-readable output. Implementations that allow ``slashification''
+within symbols will probably want write but not display to
+slashify funny characters in symbols.
+
+6.6.4 System interface
Rationale:
+For portability, load must operate on source files.
+Its operation on other kinds of files necessarily varies among
+implementations.
+
+
+
+20 February 1998
Revised5 Report on the Algorithmic Language Scheme
+
+Richard Kelsey, William Clinger, and Jonathan Rees (Editors)
+
+
+
+H. Abelson R. K. Dybvig C. T. Haynes G. J. Rozas
+N. I. Adams IV D. P. Friedman E. Kohlbecker G. L. Steele Jr.
+D. H. Bartley R. Halstead D. Oxley G. J. Sussman
+G. Brooks C. Hanson K. M. Pitman M. Wand
+Dedicated to the Memory of Robert Hieb
+R5RS
+
+
+R. Kelsey, W. Clinger, J. Rees (eds.),
+Revised5 Report on the Algorithmic Language Scheme,
+Higher-Order and Symbolic Computation, Vol. 11, No. 1,
+ August, 1998
+
+and
+ACM SIGPLAN Notices, Vol. 33, No. 9, September, 1998
+
There are two standards for Scheme: an official standard with IEEE +and a de facto one, often called +“RnRS”, short for the +Revisednth +Report on the Algorithmic Language Scheme. In colloquial use, +“Scheme standard” usually refers to the latter.
+ ++
The IEEE standard, 1178-1990 (R1995), should be available at +technical bookstores, and +from IEEE. I do not believe there are free on-line +copies available. According to the document, +
+IEEE publications are available from the Institute of Electrical and +Electronics Engineers, Service Center, 445 Hoes Lane, P.O.Box 1331, +Piscataway, NJ 08833-1331, USA. ++ + + +
You can find R7RS online, + as well as R6RS. +The Scheme Language Charter documents the +process that led to the creation of R6RS. +You can also find the older revisions, + R5RS and + R4RS, online. +
+ ++There are several categories of documents listed here: + +
+The comprehensive Scheme FAQ is now a +Wiki. +Please get involved! +
+ + ++Hari Prashanth is kindly maintaining an archive of +videos +related to both education and research. +
+ + ++
+ +Paul Graham's essays +are a trove of additional material about the Lisp family. +
+ + + ++These are textbooks dedicated to the introductory programming +curriculum and/or beginning Schemers. + +
+These are texts on advanced material that either use Scheme as the +object of study or employ Scheme to illustrate key ideas. + +
+ +The Scheme Repository has a collection of classical papers, +as the + +repository at CMU has an older one. +
+ + + ++The archives of the +RnRS authors' mailing list, dating back to 1984, have recently +become available on-line. +
+ + +The standards have been moved to their own +separate page.
+ + + + diff --git a/www/Education/index.shtml b/www/Education/index.shtml new file mode 100644 index 0000000..2daaa06 --- /dev/null +++ b/www/Education/index.shtml @@ -0,0 +1,64 @@ + + + + + + +
+
+
+
+Several institutions now use Scheme as one of the primary languages in
+their curriculum. For some years now, Terry Kaufman has conducted a
+monthly survey on
+Usenet collecting information on the use of Scheme in various courses
+at hundreds of universities and high schools. (The document is about
+35K in size.)
+
+
+
+
+
+Some educational infrastructure projects use Scheme as one of the
+primary languages:
+
+ The
+Scheme Workshop in Baltimore succesfully resolved several
+outstanding language design issues including a basic framework for
+exception handling and a mechanism for adding expressible language
+constructs (SRFI). Since time ran out on a number of other topics (including modules,
+unicode, and classes/records), Rice's Programming Language Team offers to
+organize a Scheme workshop in conjunction with POPL'99. People interested
+in attending should send email to
+Scheme in the Curriculum
+Educational Infrastructure Projects
+
+
+
+
+
+
+
diff --git a/www/Events/Workshops/Jan1999/index.shtml b/www/Events/Workshops/Jan1999/index.shtml
new file mode 100644
index 0000000..c0886c1
--- /dev/null
+++ b/www/Events/Workshops/Jan1999/index.shtml
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+Scheme '99: Call for Continuation
+
+
+
+ Trinity University
+ San Antonio, TX
+ 23 January 1999
+ Co-located with POPL'99
+
+
+
+
+
+
+
+
+The workshop will only take place if a sufficient number of people (say 15)
+have expressed interest by this deadline.
+by
+30 November 1998.
+
+The annual Scheme and Functional Programming workshop series +has its own +home page. +
+ ++
+
+ + '(schemers . org): + an improper list + of Scheme resources + [DS] + |
+ diff --git a/www/Formats/signature.shtml b/www/Formats/signature.shtml new file mode 120000 index 0000000..6830ad7 --- /dev/null +++ b/www/Formats/signature.shtml @@ -0,0 +1 @@ +suffix.shtml \ No newline at end of file diff --git a/www/Formats/ssi-config.shtml b/www/Formats/ssi-config.shtml new file mode 100644 index 0000000..75a9cc5 --- /dev/null +++ b/www/Formats/ssi-config.shtml @@ -0,0 +1 @@ + diff --git a/www/Formats/suffix.shtml b/www/Formats/suffix.shtml new file mode 100644 index 0000000..31eefc6 --- /dev/null +++ b/www/Formats/suffix.shtml @@ -0,0 +1,28 @@ + | +
+
+
+ Last modified + | ++ Powered by + |
+ | + Site Contact + | +
This page lists some of the Scheme implementations that are not in +active use but may be of interest for historical reasons. + +
There are numerous implementations of Scheme, both free and +commercial, that run on various hardware platforms and operating +systems. Many of these offer advanced facilities such as object +systems, graphical user interfaces, systems programming resources and +so forth. See the + +fairly complete list. +
+ + ++The + +FAQ provides information +on Scheme libraries. +
+ + ++There is a growing number of integrated graphical Scheme programming +environments, including those listed below. + +
+Scheme seems to inspire more than its fair share of doggerel. Like +many Scheme programs themselves, these works are brief but passionate. +They are also, unlike so many pieces that involve C or Unix or +networks, upbeat and positive; don't come here to find laments about +core dumps. Here are some examples: + +
(Imagine)
to celebrate Scheme's
+twentieth birthday.
+
++The folks at Helsinki University of Technology have created a Schememonster +to follow Alan Perlis's exhortation to ``keep fun in computing''. +
+ ++Oh yeah, did we mention the Seasonal Lisp +Machine? +
+ + + + diff --git a/www/Miscellaneous/lispm-verse.txt b/www/Miscellaneous/lispm-verse.txt new file mode 100644 index 0000000..65ed5e9 --- /dev/null +++ b/www/Miscellaneous/lispm-verse.txt @@ -0,0 +1,4 @@ +Let hackers and wireheads grovel and curse, + Chase pointers and seg fault in C; +Our LispM shall never fandango on core -- + Content with hard CDR are we! diff --git a/www/News/index.shtml b/www/News/index.shtml new file mode 100644 index 0000000..41e189c --- /dev/null +++ b/www/News/index.shtml @@ -0,0 +1,20 @@ + + + + + + +This page has been re-distributed. Activities now belong in their +own space. News will be put on the main page, +then moved into its appropriate category.
+ + + + diff --git a/www/Other/index.shtml b/www/Other/index.shtml new file mode 100644 index 0000000..7e046b2 --- /dev/null +++ b/www/Other/index.shtml @@ -0,0 +1,50 @@ + + + + + + ++Other sources of information on Scheme include archives at: + +
+The principal Scheme newsgroup is comp.lang.scheme
.
+
+Graham Hutton at the University of Nottingham maintains an +excellent Functional +Programming FAQ, which has more general information. +
+ + + + diff --git a/www/Positions/aleri-2002-02-15.txt b/www/Positions/aleri-2002-02-15.txt new file mode 100644 index 0000000..e54e303 --- /dev/null +++ b/www/Positions/aleri-2002-02-15.txt @@ -0,0 +1,16 @@ +[This posting is NO LONGER OPEN. However, you may want to keep an + eye on future openings at Aleri.] + +Aleri (www.aleri.com) is looking for strong functional programmers +interested in joining our team in NY. We are building a novel +high-performance database engine using an in-house functional language +and have plenty of interesting algorithmic problems to solve. Ideal +candidates would also have some background in databases. We are +looking to hire one or two people right away, though we may hire more +in the future. New members would join a team of a dozen talented +programmers, situated in Greenwich Village, Manhattan, that includes +myself and Jon Riecke. Aleri is startup company with significant +revenue as well as VC funding, and offers both stock options and +competitve salary compensation. + +Andrew Wright (andrew.wright@aleri.com) diff --git a/www/Positions/content-integrity-2000-6-23.txt b/www/Positions/content-integrity-2000-6-23.txt new file mode 100644 index 0000000..26f2733 --- /dev/null +++ b/www/Positions/content-integrity-2000-6-23.txt @@ -0,0 +1,119 @@ +Time-stamp: <00/06/25 13:40:27 shriram> + added text about Scheme with Joe Marshall's permission + +Time-stamp: <00/06/23 14:06:32 shriram> + original posting + +[Though this posting is about Common Lisp jobs, the company welcomes + and may consider at an advantage Schemers who are willing to make the + transition to Common Lisp and thus harness skills from both paradigms.] + +Content Integrity is developing Webcentric Change Management products +for Business-to-Business ("B2B") web sites. This is an exciting +newly-funded startup opportunity, equity is available, and candidates +will be responsible for developing state of the art web applications. + +The positions below are described from back-end to front-end. Back +end developers should be bit tweakers who know how to make scalable +high performance data stores on object and/or relational +databases. Front end developers should be top notch web application +developers who know every DHTML and Java applet browser interface +trick in the book. In the middle are people familiar with application +servers and all that goes with it (load balancing, parallelism, and +every socket/security/authentication protocol under the sun). + +Most of the product is coded in Common Lisp and Java, but a variety of +other language and technology skills are required depending on the +position. There are some substantial data modeling and analysis tasks +centered on XML and HTML. The models will be built using our unique +versioned modeling engine. + +The environment is friendly, relatively ego-free, and occasional +telecommuting is okay. "Can-do" people will be rewarded, whether +you're just out of school or you've been doing this work for 20 years. + +The office location is TBD since we're going to get new office space +one way or the other. Currently CII is in Braintree, but we're +considering moving to points north. The commute is traffic-free +(opposite the heavy volume traffic flows). It's 23 minutes from the +route 20 / route 128 intersection, and 20 minutes from Boston. We're +right on the Braintree red line and commuter rail stop. + +Please send resumes to jobs@content-integrity.com. Principals only, +please. + + + General Skills + +* Cross platform, HP/UX, Solaris, Linux, Windows NT. +* C, C++, Common Lisp, Java. +* Understanding revision/version/change/configuration + management principles a big plus. +* Web application development experience. + + Database (2 positions) (C/C++, Common Lisp) + +* Large scale object database work with ObjectStore. +* Low level database representations to achieve optimal + clustering and compaction (including compression) of data. +* Nested and parallel transactions, deadlock avoidance, + transaction restarts, hierarchical lock models. +* Top notch object-relational mapping skills for + deploying relational-db solutions based on complex, high + performance object models. +* Superlative Objectstore and Common Lisp skills to + develop Lisp to ObjectStore interfaces. + + Application Server (3 positions) + (COM, CORBA, JavaBeans, Common Lisp, Java) + +* Load balancing techniques. +* Strong HTTP protocol experience, request forwarding, + secure sockets, SHTTP. +* Compressed and secure data transmissions, + authentication, directory services integration (LDAP). +* Proxy servers and other HTTP oriented cache techniques. +* Microsoft Office Server Extensions APIs. + + XML, HTML model development (2 people) (Common Lisp, Java) + +* Stong knowledge of W3C XML specifications, experience + writing and using XML processors. +* Experience writing HTTP/HTML spiders and analyzing HTML + page content. + + XML, HTML UI development (2 positions) (Common Lisp, Java) + +* Experience developing DHTML and/or Java AWT Applet + based interfaces for presenting structural interfaces for + navigation and presentation of XML and HTML content. + + Web application user interface specialist (1 position) (DHTML, XML) + +* Experience developing state of the art user-friendly + web application interfaces with DHTML for diverse browser + clients. EXPERT with Javascript and all the tools of the + trade for developing elegant and effective web application + interfaces. + +* Ability to design the total navigation scheme for an + application that really flows for non-technical application users. + + Quality Assurance Positions (3 Positions) + + This is not your average QA position. You'll be called + upon to code, script, and work with third party tools + that ensure robust 24x7 mission and data critical web + application operation. + +* Common Lisp and/or cross-platform PERL scripting + experience. +* Experience writing unit tests in Common Lisp and/or + Java. +* Experience writing object-database tests at the API + level (any language) +* Experience with user-agent (browser, http-client) UI + testing. +* CROSS PLATFORM REGRESSION experience a must. Our tests + and test agents must run on Windows NT and Unix equally + well. diff --git a/www/Positions/dartmouth-2004-09-08.txt b/www/Positions/dartmouth-2004-09-08.txt new file mode 100644 index 0000000..04ef8dc --- /dev/null +++ b/www/Positions/dartmouth-2004-09-08.txt @@ -0,0 +1,19 @@ +We're looking for an experienced Scheme programmer at Darmouth +College's Interactive Media Lab, in Lebanon, New Hampshire: + + http://iml.dartmouth.edu/ + +We're working on two related projects right now: Training software for +first responders, and our underlying multimedia engine, Tamale: + + http://iml.dartmouth.edu/tamale/ + +We need somebody to help out on both projects. Desirable skills +include: + + * Scheme or LISP + * C++ + * Multimedia development + * User interface design + +Contact eric DOT kidd AT dartmouth DOT edu for more information. diff --git a/www/Positions/getdemocracy-2006-12-15.txt b/www/Positions/getdemocracy-2006-12-15.txt new file mode 100644 index 0000000..4b3d0d3 --- /dev/null +++ b/www/Positions/getdemocracy-2006-12-15.txt @@ -0,0 +1,19 @@ +Participatory Culture Foundation makes the open-source video RSS app, +Democracy Player - getdemocracy.com + +We're looking for a top-notch programmer who can work independently, +communicate well, and occasionally step back from the code to +contemplate improvements to program architecture or our development +process. Most of our code is in dynamic languages like Python and +Ruby, so a clear understanding of language concepts is important. +Our developers are fans of Scheme and we think that someone who knows +Lisp / Scheme would make a good candidate for joining our +organization. + +We are a new organization based in Worcester, MA but do not require +that the developer move to Worcester-- you may work remotely. This is +a full-time position working on Democracy Player related projects. + +TO APPLY: Send a short note about why you're interested in working +with us along with a casual resume or description of what your +skills / experience is to jobs@pculture.org. diff --git a/www/Positions/hamilton-2010-04-29.txt b/www/Positions/hamilton-2010-04-29.txt new file mode 100644 index 0000000..8ac69b8 --- /dev/null +++ b/www/Positions/hamilton-2010-04-29.txt @@ -0,0 +1,25 @@ + Functional Programming and Automatic Differentiation + + PhD Studentships + Postdoctoral Positions + +We are adding exact first-class derivative calculation operators +(Automatic Differentiation or AD) to the lambda calculus, and +embodying the combination into a production-quality optimising +compiler. Our research prototype compiler generates object code +competitive with the fastest current systems, which are based on +FORTRAN. We are seeking PhD students and postdocs with interest and +experience in relevant areas: programming language theory, numeric +computing/numeric linear algebra, or differential geometry; and a +burning drive to help lift big iron numeric computing out of the 1960s +and into a newer higher order. Specific sub-projects include: +compiler and numeric programming environment construction; writing, +simplifying, and generalising numeric algorithms through the use of AD +operators; and associated type/lambda calculus/PLT/real computation +issues. + +The project headquarters will be in the Hamilton Institute, NUI +Maynooth, Ireland, http://www.hamilton.ie/. + +Applications to: + "Barak A. Pearlmutter"+Though this site does not endorse any particular commercial +organization, we are enthusiastic about the existence of Functional Jobs, which posts +information about jobs that demand functional programmers. Please +take a look at their offerings. (However, note that we have not +vetted their content.) +
+ + + ++Here are other known positions; some of these may since have been +filled: + +
+If you are interested in posting a job advertisement here, please +contact the maintainer! +
+ + + + diff --git a/www/Positions/infineon-2005-02-07.txt b/www/Positions/infineon-2005-02-07.txt new file mode 100644 index 0000000..6ca63e6 --- /dev/null +++ b/www/Positions/infineon-2005-02-07.txt @@ -0,0 +1,33 @@ +This is posted on behalf of Infineon Technologies. + +Essential Duties and Responsibilities: + +We're looking for a Software Engineer to join the Silicon Validation +Group in the Optical Networking department (3 months temporary +employment) in San Jose, CA. In this function you will work on the +test automation environment and write test scripts for particular +designs. If required you will also write low level device API's to +simplify the software interface to the design. + +Education & Experience: + +You should possess a B.S. or M.S. degree in Computer Science or +engineering with at least three years of experience + +Additional qualifications include: + +-Knowledge of Scheme, C, Tcl/tk +-Fundamental knowledge of networks and networking technology including + but not limited to SONET/SDH, GFP, VCAT/LCAS, TCP/IP, Ethernet, Fibre + Channel. +-Knowledge of software automation to enable automated testing with + various test equipment. +-Basic knowledge of lab tools like oscilloscopes or logic analyzers. + +In this position you will contribute to the product validation from +the time it's being handed over from the design group to the time it's +been delivered to the customer. Commitment to quality and a desire to +understand the root cause of a problem are key for a validation +engineer. + +Please e-mail your resume to amy.schroyer@infineon.com diff --git a/www/Positions/intranexus-2005-10-03.txt b/www/Positions/intranexus-2005-10-03.txt new file mode 100644 index 0000000..444672f --- /dev/null +++ b/www/Positions/intranexus-2005-10-03.txt @@ -0,0 +1,49 @@ +JOB DESCRIPTION: + +We are seeking highly motivated and experienced developers to work +with a dynamic group of focused and creative individuals to design and +develop an exciting new product in a fast-paced, sometimes stressful +environment. + +RESPONSIBILITIES: + +Analyze, design, and develop a Java-based, n-tier application software +package. + +EDUCATION: + +Requires Bachelor's degree or technical certification or equivalent +work experience. + +REQUIRED SKILLS: + +. Experience with a functional programming language such as Scheme + or Lisp. +. 5+ years experience in object-oriented development +. 3+ years of strong hands-on development experience in Java + programming, including J2EE platform and design patterns +. Ability to navigate in multiple computing environments + (Solaris, AIX, Linux, Windows) +. Knowledge of Internet and Web technology +. Ability to take initiative, be flexible and work independently or + with a team +. Experience in the development of relational database applications +. Excellent verbal and written communication skills +. Willingness to travel + +DESIRED SKILLS: + +. Experience with XML, XSLT, Hibernate, and JUnit +. Large application development + +Description: + +IntraNexus is a healthcare software development company, working on +the leading edge of technology. + +IntraNexus offers an energetic, team-oriented work environment, +opportunities for career advancement, competitive salaries, and +excellent benefits (health, dental, life, disability, vision, 401k, +retirement, profit sharing, pre-tax reimbursement). + +Please send your resume to bmoore@intranexus.com. \ No newline at end of file diff --git a/www/Positions/isgroup-2004-06-08.txt b/www/Positions/isgroup-2004-06-08.txt new file mode 100644 index 0000000..142a8ad --- /dev/null +++ b/www/Positions/isgroup-2004-06-08.txt @@ -0,0 +1,14 @@ +We are looking for a Scheme P/A for a contract or a job with a client +in Miami, FL. The salary level or contract rate will depend on +experience. If you are interested, please send a resume. Mike +Kenneth + +Mike Kenneth +The I.S. Group Inc. +P.O. Box 810773 +Boca Raton, FL 33481-0773 +800 239 0056 + +mkenneth@isgroupinc.com + +http://isgroupinc.com/ diff --git a/www/Positions/lshift-2002-10-16.txt b/www/Positions/lshift-2002-10-16.txt new file mode 100644 index 0000000..36d6edb --- /dev/null +++ b/www/Positions/lshift-2002-10-16.txt @@ -0,0 +1,46 @@ +LShift Vacancies + +http://www.lshift.net/jobs.shtml + +We are looking for developers with proven experience in a 'commercial +environment' to start as soon as possible for a negotiable salary. +Options/equity available for the right people. +Specific Requirements + +At least three of the following areas: + + * Concurrency theory, process calculi, linear logic + * Distributed systems + * Functional programming and logic programming + * Virtual machine implementation + * Compiler implementation + * O/S implementation + * .NET, C#, VC++, COM and Windows in general + * extending MS applications, e.g. VisualStudio, Visio + +General Requirements + +Applicants should be 'all-rounders' with the following basic skill set: + + * Good Unix and Windows experience + * Versed in several (>3) programming languages + +Other areas of experience are likely to include: + + * Databases / SQL + * Web development + * System administration + * IT security + * XML, EJB, Corba + * Apache / IIS + * Version control systems + * IDEs + * CMSs + +Other characteristics we are expecting of applicants: + + * You take responsibility seriously + * You are considered to be opinionated about at least one tech issue + * You are sometimes observed to be laughing without good reason + * You're not the kind of person that will reply complaining about + how unrealistic this job spec is diff --git a/www/Positions/mak-2005-03-30.txt b/www/Positions/mak-2005-03-30.txt new file mode 100644 index 0000000..5c09384 --- /dev/null +++ b/www/Positions/mak-2005-03-30.txt @@ -0,0 +1,41 @@ +MAK develops solutions to link, simulate and visualize the virtual +world. We also leverage our experience to provide custom simulation +solutions. MAK builds PC-based leadership trainers, tailored product +enhancements, and custom synthetic environments to meet our customers' +needs. MAK's software products are C++ libraries for simulation +networking, 3D graphics, physics-based simulation, and tactical-map +user interfaces. Our custom simulation solutions and trainers build +upon and expand our product offerings for targeted solutions to +customer problems. Our work also includes research and development in +networking, graphical user interfaces, display management, applied +artificial intelligence, and distributed computing. + +Applied AI Engineer + +We are now looking for an Applied AI Engineer to help us design, +develop and support our simulation software toolkits and applications. +Candidates should have a strong background in practical application of +artificial intelligence theory, methodologies and tools (e.g., +Bayesian belief networks, rule-based systems, intelligent agents), and +should also have strong object-oriented design skills and experience +developing commercial software. + +BSCS, MSCS or equivalent, plus at least 6 years relevant experience. +Significant prior experience developing applications with C++ and Lisp +is required. We have close relationships with our customers, and +therefore good verbal and written communication skills are also +required. + +Experience with one or more of the following is a plus: +- Proposal writing +- Distributed agent architectures, domain specific languages +- Real-time simulation +- C4I system development +- Product quality API development +- Reusable class framework implementation + +Please send resumes via postal or electronic mail ONLY to: Human +Resources, MAK Technologies, Inc., 10 Fawcett St., Cambridge, MA 0213; +E-mail: hr@mak.com Principals only, please. + +MAK is an Equal Opportunity Employer. diff --git a/www/Positions/memetrics-2000-11-16.txt b/www/Positions/memetrics-2000-11-16.txt new file mode 100644 index 0000000..b415b42 --- /dev/null +++ b/www/Positions/memetrics-2000-11-16.txt @@ -0,0 +1,43 @@ +[Editorial Note: The Chief Technology Officer is Ken Dickey, a + long-standing contributor in Lisp and Scheme circles.] + +Subject: International search for Lisp programmers, Memetrics P/L (Sydney, +Australia) + +Memetrics (Sydney, Australia) + +As a result of new product developments and continued growth, +Memetrics is conducting a world-wide search for software engineers +experienced in Lisp or other functional programming languages and +related technologies. + +Memetrics is a group of leading international engineers, scientists, +and business professionals who are working together to implement a +range of radically new presentation optimization systems using +Lisp. We have attracted substantial private and government funding and +our first product, XOS, was launched in San Francisco this week. For +more company details, see our website, www.memetrics.com + +Because we're a young organization, you will have an excellent +opportunity to have an impact on the evolution of the company. We +offer a great work environment full of interesting and challenging +problems. + +Required Experience and Skills + +Ideally you will possess at least three years experience in an object +oriented development environment. Exposure to Lisp and CORBA in a +commercial setting would be advantageous. Candidates should be +comfortable using Unix and/or NT. Successful candidates also must +have excellent communication skills, and be willing to work closely +within a tight-knit team. Experience with SQL would also be helpful. + +Salary + +Compensation is based on skills and previous experience in addition to +a generous pre-IPO stock option package. Australian and overseas +applicants will be considered. Come to the city of which Lonely Planet +says "...you would have to die and go to heaven before you see a more +spectacular setting for a city." + +Please send resumes to jobs@memetrics.com diff --git a/www/Positions/merced-systems-2004-05-13.txt b/www/Positions/merced-systems-2004-05-13.txt new file mode 100644 index 0000000..65cf12d --- /dev/null +++ b/www/Positions/merced-systems-2004-05-13.txt @@ -0,0 +1,24 @@ +Merced Systems is looking for senior level developers who are familiar +with Scheme and are excited to be developing with Scheme in a product +development environment. + +We are looking for developers who can join Merced's development team +in designing and building our expanding product line. + +This is a classic software development position within a product +company. As such, the main skill desired is the ability to solve +extremely complex problems in a short amount of time in a way that is +harmonious with our overarching design and strategy. You must be very +creative and very hard working with an excellent design sense. We are +also looking for an individual with a phenomenal implementation +ability. + +We are located in beautiful Redwood Shores, CA just south of San +Francisco. + +Please send your resume to tech-jobs@mercedsystems.com with only "Lead +Developer Application" in the title of the email. Please send your +resume in one of the following formats: Plain ASCII, PDF, or HTML +only. Thank you. + +See http://www.mercedsystems.com/careers.html for more details. diff --git a/www/Positions/nasa-ames-2000-5-31.txt b/www/Positions/nasa-ames-2000-5-31.txt new file mode 100644 index 0000000..68a5401 --- /dev/null +++ b/www/Positions/nasa-ames-2000-5-31.txt @@ -0,0 +1,59 @@ +[This posting is NO LONGER OPEN. However, you may want to keep an + eye on future openings at NASA Ames.] + +Newsgroups: comp.lang.scheme +Organization: NASA/Raytheon +Message-ID: <8h3q7i$mgk$1@nnrp1.deja.com> +From: K. Michael Dalal+This page will list some of the large-scale uses of Scheme, in both +commercial applications and prominent free software. +
+ +The GIMP is an image +manipulation program freely redistributable under the GNU Public Licence. It +provides extensive scripting capabilities via +an embedded Scheme interpreter, allowing users to create images +procedurally from a Scheme program.
+ +The Scheme window manager, scwm, is a window manager for +X-Windows written in Guile. Users can configure Scwm by writing +Scheme code.
+ + GNOME AisleRiot uses Scheme for most of its programming.
+(Reported by Shlomi Fish (shlomif@vipe.technion.ac.il
).)
The
+Festival speech synthesis package probably uses Scheme; at
+least, that's what its command line interface uses.
+(Reported by Nathan Valentine nrvale0@pop.uky.edu
.)
The
+Sawfish window manager is written in Lisp.
+(Reported by Nathan Valentine nrvale0@pop.uky.edu
.)
+Several people have created Scheme-related loot; here are some +samples: +
+
+
+(welcome '(schemers . org))
+
+ |
+
+
I intend this but for a Scheme of a larger Design. + --Woodward, Nat. Hist. Earth, 1723 |
+
+News Items and Announcements +
+ ++Please check out the Scheme workshops from +2014, +2015, +2016 +(with videos), +2017 +(with videos), +2018 +(with videos), +and +2019 +(with videos). +
+ ++Manuel Serrano was invited to give a seminar on Hop to +the +Collège de France. +
+ ++Now that both +R6RS +and +R7RS Small +have been ratified, work has begun on +R7RS Large. +
+ ++Blogspace is alive with good Scheme articles. +See Planet Scheme! +You can also find some articles +linked from here. +
+ ++Check out the Scheme Meetup site. +
+ ++The Regular Fare +
+ ++
+
+(case (what-would-you-like-to-do?) + ((learn) + (choose-from FAQ + textbooks + videos + blogs + standards + tutorials + other documents + education)) + ((program) + (choose-from implementations + libraries + environments + Reqests for Implementation (SRFI))) + ((socialize) + (choose-from ABQ Lisp/Scheme - Albuquerque, NM, USA + Bay Area Lisp & Scheme - Bay Area, CA, USA (videos) + Boston Lisp Announce - Boston, MA, USA + Scheme UK - London, UK + munich-lisp - Munich, Germany + CRACL - Los Angeles, CA, USA + Lambdaheads - Vienna, Austria + FringeDC - Washington, DC, USA)) + ((work) + (choose-from jobs)) + ((stay-informed) + (choose-from events)) + (else + (choose-from the lighter side + wares + other resources)))+ + |
+
+(If you're looking for the fine folks of Schemers Inc., they're at +www.schemers.com.) +
+ + + + + diff --git a/www/logo-contrib.mbox b/www/logo-contrib.mbox new file mode 100644 index 0000000..34211f0 --- /dev/null +++ b/www/logo-contrib.mbox @@ -0,0 +1,1002 @@ +From VM Thu Dec 2 16:13:48 1999 +X-VM-Message-Order: + (1 2 5 6 3 4 7 8) +X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" +X-VM-Labels: nil +X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil +X-VM-Last-Modified: (14932 59282 19853) +X-VM-POP-Retrieved: nil +X-VM-Bookmark: 1 +Content-Length: 3982 +Status: RO +X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] + ["3982" "Thu" "2" "December" "1999" "14:07:54" "-0800" "Maria Smith" "maria@axiomweb.com" "<10588.991202@axiomweb.com>" "66" "logo" "^From:" nil nil "12" "1999120222:07:54" "logo" nil nil nil] + nil) +Return-Path:+Welcome to schemers.org! This is a collection of resources for the +Scheme programming language. It was initiated by the +PLT group at +Rice University. +It now runs on a server in the +Brown University computer +science department. +
+ +
+The pages were built and are maintained by Shriram Krishnamurthi,
+with help from other members of Rice PLT, most notably
+Matthias Felleisen,
+Paul Steckler and
+Yan-David Erlich.
+Comments, suggestions and contributions of material are always
+welcome. Please contact me at sk+59@cs.brown.edu
.
+
+Several people have contributed logos for this site. The current logo +is from Dan Sandler, a +Rice graduate who spent a summer working with PLT. He wrote Scheme +code to rework the Rice computer science department's entire Web site, +and thus got the group thinking seriously about the Web. Thanks, Dan! +
+ ++The ``favorite'' icon the little lambda that you might see +associated with this site in some browsers, especially if you bookmark +any of its pages was generated by Mason Loring Bliss. Thanks, +Mason! +
+ + + +