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