From 0644ff84ecc8ad88111adaa1b9f0ead5058666b9 Mon Sep 17 00:00:00 2001 From: Lassi Kortela Date: Tue, 24 Jan 2023 23:13:22 +0200 Subject: [PATCH] Add missing status-feb06.html Linked from status-jun06.html, spotted by linklint. Rescued from https://legacy.cs.indiana.edu/~dyb/r6rs/status-feb06.html --- .../Charter/status-jun-2006/status-feb06.html | 717 ++++++++++++++++++ 1 file changed, 717 insertions(+) create mode 100644 www/Documents/Standards/Charter/status-jun-2006/status-feb06.html diff --git a/www/Documents/Standards/Charter/status-jun-2006/status-feb06.html b/www/Documents/Standards/Charter/status-jun-2006/status-feb06.html new file mode 100644 index 0000000..edbe506 --- /dev/null +++ b/www/Documents/Standards/Charter/status-jun-2006/status-feb06.html @@ -0,0 +1,717 @@ + + + + + +R6RS Status Report + + + + + + + +

R6RS Status Report

+

Kent Dybvig, Will Clinger, Matthew Flatt, Mike Sperber, and Anton van Straaten

+

February 24, 2006

+ + +

+ + +

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
1. Overview
2. Guiding Principles
3. Decisions
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
3.1. Structural changes
3.2. Features eliminated
3.3. Changes
3.4. Features added
3.5. Features to be added
3.6. Reaffirmations
3.7. Beyond R6RS
4. Work in Progress
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
4.1. Libraries
4.2. Records
4.3. Unicode
4.4. Arithmetic
4.5. Exceptions
4.6. I/O
4.7. Macros
4.8. Other possible changes
5. Completion Process
+ + +

+ + + + +

1. Overview

+ + + + +

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

+ + + + +

2. Guiding Principles

+ + + + +

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

+ + + + +

3. Decisions

+ + + + +

+This section outlines the decisions made to date. + +

+ + + + +

3.1. Structural changes

+ + + + +

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

+

+ +

+ + + + +

3.2. Features eliminated

+ + + + +

+The following features have been eliminated. + +

+

+ +

+ + + + +

3.3. Changes

+ + + + +

+The following syntactic and semantic changes have been made to existing +features. + +

+

+ +

+ + + + +

3.4. Features added

+ + + + +

+The following features have been added. + +

+

+ +

+ + + + +

3.5. Features to be added

+ + + + +

+The following features will be added once the details have been worked out. + +

+

+ +

+ + + + +

3.6. Reaffirmations

+ + + + +

+The following features of R5RS are reaffirmed for R6RS. + +

+

+ +

+ + + + +

3.7. Beyond R6RS

+ + + + +

+The following features are definitely not under consideration for R6RS. + +

+

+ +

+ + + + +

4. Work in Progress

+ + + + +

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

+ + + + +

4.1. Libraries

+ + + + +

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

+ + + + +

4.2. Records

+ + + + +

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

+ + + + +

4.3. Unicode

+ + + + +

+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). + +

+ + + + +

4.4. Arithmetic

+ + + + +

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

+ + + + +

4.5. Exceptions

+ + + + +

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

+ + + + +

4.6. I/O

+ + + + +

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

+ + + + +

4.7. Macros

+ + + + +

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

+ + + + +

4.8. Other possible changes

+ + + + +

+The following possible features and changes have been discussed without +resolution. + +

+

+ + +

+ + + + +

5. Completion Process

+ + + + +

+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). + +

+ + + +