678 lines
20 KiB
HTML
678 lines
20 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd"><!-- DO NOT EDIT THIS FILE-->
|
|
<!-- Edit the .tex version instead-->
|
|
|
|
<html>
|
|
<head>
|
|
<title>R6RS Status Report</title>
|
|
<link href="status.css" rel="stylesheet" type="text/css">
|
|
</head>
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<h1>R6RS Status Report</h1>
|
|
<h2>Kent Dybvig, Will Clinger, Matthew Flatt, Mike Sperber, and Anton van Straaten</h2>
|
|
<h3>February 24, 2006</h3>
|
|
|
|
|
|
<p>
|
|
|
|
|
|
<p>
|
|
|
|
<table cellpadding=0 cellspacing=0>
|
|
|
|
|
|
|
|
<tr><td align="right"><b>1. </b><td><b><a class=plain href="./status-mar-2006.html#g0">Overview<a name="sect:overview"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td align="right"><b>2. </b><td><b><a class=plain href="./status-mar-2006.html#g1">Guiding Principles<a name="sect:principles"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td align="right"><b>3. </b><td><b><a class=plain href="./status-mar-2006.html#g2">Decisions<a name="sect:decisions"></a></a></b></td></tr>
|
|
|
|
|
|
<tr><td></td><td><table cellpadding=0 cellspacing=0>
|
|
<tr><td><b>3.1. </b></td><td><b><a class=plain href="./status-mar-2006.html#g3">Structural changes</a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>3.2. </b></td><td><b><a class=plain href="./status-mar-2006.html#g4">Features eliminated</a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>3.3. </b></td><td><b><a class=plain href="./status-mar-2006.html#g5">Changes</a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>3.4. </b></td><td><b><a class=plain href="./status-mar-2006.html#g6">Features added</a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>3.5. </b></td><td><b><a class=plain href="./status-mar-2006.html#g7">Features to be added<a name="featurestobeadded"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>3.6. </b></td><td><b><a class=plain href="./status-mar-2006.html#g8">Reaffirmations</a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>3.7. </b></td><td><b><a class=plain href="./status-mar-2006.html#g9">Beyond R<sup>6</sup>RS</a></b></td></tr>
|
|
|
|
|
|
</table></td></tr>
|
|
<tr><td align="right"><b>4. </b><td><b><a class=plain href="./status-mar-2006.html#g10">Work in Progress<a name="sect:workinprogres"></a></a></b></td></tr>
|
|
|
|
|
|
<tr><td></td><td><table cellpadding=0 cellspacing=0>
|
|
<tr><td><b>4.1. </b></td><td><b><a class=plain href="./status-mar-2006.html#g11">Libraries<a name="progress:libraries"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.2. </b></td><td><b><a class=plain href="./status-mar-2006.html#g12">Records<a name="progress:records"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.3. </b></td><td><b><a class=plain href="./status-mar-2006.html#g13">Unicode<a name="progress:unicode"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.4. </b></td><td><b><a class=plain href="./status-mar-2006.html#g14">Arithmetic<a name="progress:arithmetic"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.5. </b></td><td><b><a class=plain href="./status-mar-2006.html#g15">Exceptions<a name="progress:exceptions"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.6. </b></td><td><b><a class=plain href="./status-mar-2006.html#g16">I/O<a name="progress:io"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.7. </b></td><td><b><a class=plain href="./status-mar-2006.html#g17">Macros<a name="progress:macros"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
<tr><td><b>4.8. </b></td><td><b><a class=plain href="./status-mar-2006.html#g18">Other possible changes<a name="progress:miscellaneous"></a></a></b></td></tr>
|
|
|
|
|
|
</table></td></tr>
|
|
<tr><td align="right"><b>5. </b><td><b><a class=plain href="./status-mar-2006.html#g19">Completion Process<a name="sect:process"></a></a></b></td></tr>
|
|
|
|
|
|
|
|
|
|
</table>
|
|
|
|
|
|
<p>
|
|
|
|
<a name="g0"></a>
|
|
|
|
<h3><br><a name="./status:h0"></a>1. Overview<a name="sect:overview"></a></h3>
|
|
|
|
|
|
|
|
<p>
|
|
This status report describes the current state of the R<sup>6</sup>RS
|
|
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 R<sup>6</sup>RS.
|
|
|
|
<p>
|
|
|
|
<a name="g1"></a>
|
|
|
|
<h3><br><a name="./status:h1"></a>2. Guiding Principles<a name="sect:principles"></a></h3>
|
|
|
|
|
|
|
|
<p>
|
|
To help guide the standardization effort, the editors have adopted a
|
|
set of principles, presented below.
|
|
They are, like R<sup>6</sup>RS itself, a work in progress and still subject
|
|
to change.
|
|
|
|
<p>
|
|
Like R<sup>5</sup>RS Scheme, R<sup>6</sup>RS Scheme should:
|
|
|
|
<p>
|
|
<ul>
|
|
<li>derive its power from simplicity, a small number of generally
|
|
useful core syntactic forms and procedures, and no unnecessary
|
|
restrictions on how they are composed;
|
|
|
|
<p>
|
|
<li>allow programs to define new procedures and new hygienic
|
|
syntactic forms;
|
|
|
|
<p>
|
|
<li>support the traditional s-expression representation of program
|
|
source code as data;
|
|
|
|
<p>
|
|
<li>make procedure calls powerful enough to express any form of
|
|
sequential control, and allow programs to perform non-local control
|
|
operations without the use of global program transformations;
|
|
|
|
<p>
|
|
<li>allow interesting, purely functional programs to run indefinitely
|
|
without terminating or running out of memory on finite-memory
|
|
machines;
|
|
|
|
<p>
|
|
<li>allow educators to use the language to teach programming
|
|
effectively, at various levels and with a variety of pedagogical
|
|
approaches;
|
|
and
|
|
|
|
<p>
|
|
<li>allow researchers to use the language to explore the design,
|
|
implementation, and semantics of programming languages.
|
|
</ul>
|
|
|
|
<p>
|
|
In addition, R<sup>6</sup>RS Scheme should:
|
|
|
|
<p>
|
|
<ul>
|
|
<li>allow programmers to create and distribute substantial
|
|
programs and libraries, e.g., SRFI implementations, that run
|
|
without modification in a variety of Scheme implementations;
|
|
|
|
<p>
|
|
<li>support procedural, syntactic, and data abstraction more fully
|
|
by allowing programs to define hygiene-bending and hygiene-breaking
|
|
syntactic abstractions and new unique datatypes along with
|
|
procedures and hygienic macros in any scope;
|
|
|
|
<p>
|
|
<li>allow programmers to rely on a level of automatic run-time type
|
|
and bounds checking sufficient to ensure type safety while also
|
|
providing a standard way to declare whether such checks are
|
|
desired;
|
|
and
|
|
|
|
<p>
|
|
<li>allow implementations to generate efficient code, without requiring
|
|
programmers to use implementation-specific operators or
|
|
declarations.
|
|
</ul>
|
|
|
|
<p>
|
|
In general, R<sup>6</sup>RS 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.
|
|
|
|
<p>
|
|
R<sup>6</sup>RS Scheme should also be backward compatible with programs
|
|
written in R<sup>5</sup>RS 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.
|
|
|
|
<p>
|
|
|
|
<a name="g2"></a>
|
|
|
|
<h3><br><a name="./status:h2"></a>3. Decisions<a name="sect:decisions"></a></h3>
|
|
|
|
|
|
|
|
<p>
|
|
This section outlines the decisions made to date.
|
|
|
|
<p>
|
|
|
|
<a name="g3"></a>
|
|
|
|
<h4><br><a name="./status:h3"></a>3.1. Structural changes</h4>
|
|
|
|
|
|
|
|
<p>
|
|
R6RS will consist of a core language and set of separate libraries.
|
|
|
|
|
|
<p>
|
|
The following features are definitely in the core language:
|
|
|
|
<p>
|
|
<ul>
|
|
<li><i>none yet identified</i>
|
|
</ul>
|
|
|
|
<p>
|
|
The following features are definitely in a separate library.
|
|
|
|
<p>
|
|
<ul>
|
|
<li><tt>delay</tt> and <tt>force</tt>
|
|
<li>hash tables (see Section <a href="./status-mar-2006.html#g7">3.5</a>)
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g4"></a>
|
|
|
|
<h4><br><a name="./status:h4"></a>3.2. Features eliminated</h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following features have been eliminated.
|
|
|
|
<p>
|
|
<ul>
|
|
<li><tt>transcript-on</tt> and <tt>transcript-off</tt>
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g5"></a>
|
|
|
|
<h4><br><a name="./status:h5"></a>3.3. Changes</h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following syntactic and semantic changes have been made to existing
|
|
features.
|
|
|
|
<p>
|
|
<ul>
|
|
<li>syntax is case sensitive
|
|
<li>internal defines now follow <tt>letrec*</tt> semantics
|
|
<li>there is now a single unique end-of-file object
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g6"></a>
|
|
|
|
<h4><br><a name="./status:h6"></a>3.4. Features added</h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following features have been added.
|
|
|
|
<p>
|
|
<ul>
|
|
<li><tt>letrec*</tt> (<tt>letrec</tt> with left-to-right evaluation order)
|
|
<li>block comments bracketed by <tt>#|</tt> and <tt>|#</tt>
|
|
<li>expression comments prefixed by <tt>#;</tt>
|
|
<li>matched square brackets ("<tt>[</tt>" and "<tt>]</tt>");
|
|
equivalent to matched parentheses for list data and
|
|
list-structured forms
|
|
<li>allow symbols to start with <tt>-></tt>
|
|
<li><tt>eof-object</tt> constructor to obtain the end-of-file object
|
|
<li>require continuations created by <tt>begin</tt> to accept any number
|
|
of values
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g7"></a>
|
|
|
|
<h4><br><a name="./status:h7"></a>3.5. Features to be added<a name="featurestobeadded"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following features will be added once the details have been worked out.
|
|
|
|
<p>
|
|
<ul>
|
|
<li>top-level libraries
|
|
<li>record types and record definitions
|
|
<li>exception handling
|
|
<li>safe (default) and unsafe modes
|
|
<li><tt>syntax-case</tt> macros
|
|
<li>hash tables (as a library)
|
|
<li>Unicode support
|
|
<li>new string escape characters, including <tt>\n</tt> for newline
|
|
(part of Unicode support)
|
|
<li>serialization (read-write invariance) for every datum
|
|
(part of Unicode support)
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g8"></a>
|
|
|
|
<h4><br><a name="./status:h8"></a>3.6. Reaffirmations</h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following features of R<sup>5</sup>RS are reaffirmed for R<sup>6</sup>RS.
|
|
|
|
<p>
|
|
<ul>
|
|
<li>support for multiple values
|
|
<li>unspecified evaluation order for applications, <tt>let</tt> bindings, and <tt>letrec</tt> bindings
|
|
<li><tt>set-car!</tt> and <tt>set-cdr!</tt>
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g9"></a>
|
|
|
|
<h4><br><a name="./status:h9"></a>3.7. Beyond R<sup>6</sup>RS</h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following features are definitely not under consideration for R<sup>6</sup>RS.
|
|
|
|
<p>
|
|
<ul>
|
|
<li>processes
|
|
<li>network programming
|
|
<li>object-oriented programming
|
|
<li>box datatype
|
|
</ul>
|
|
|
|
<p>
|
|
|
|
<a name="g10"></a>
|
|
|
|
<h3><br><a name="./status:h10"></a>4. Work in Progress<a name="sect:workinprogres"></a></h3>
|
|
|
|
|
|
|
|
<p>
|
|
Most of the standardization effort is currently focused on several
|
|
subsystems: libraries, records, Unicode, arithmetic, exceptions, I/O,
|
|
modules, and hash tables.
|
|
Sections <a href="./status-mar-2006.html#g11">4.1</a>-<a href="./status-mar-2006.html#g17">4.7</a> list for
|
|
each subsystem a set of informal requirements the editors have
|
|
identified, the current status, and open questions.
|
|
|
|
<p>
|
|
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 R<sup>6</sup>RS may, however, differ in minor
|
|
or significant ways from the published SRFI.
|
|
|
|
<p>
|
|
A list of other items up for consideration is given in
|
|
Section <a href="./status-mar-2006.html#g18">4.8</a>.
|
|
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.
|
|
|
|
<p>
|
|
|
|
<a name="g11"></a>
|
|
|
|
<h4><br><a name="./status:h11"></a>4.1. Libraries<a name="progress:libraries"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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
|
|
<tt>import</tt> and <tt>export</tt> forms is tied down,
|
|
what built-in libraries besides <tt>r6rs</tt> there might
|
|
be, and whether there is to be support for user-defined
|
|
libraries.
|
|
|
|
<p>
|
|
|
|
<a name="g12"></a>
|
|
|
|
<h4><br><a name="./status:h12"></a>4.2. Records<a name="progress:records"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
Informal requirements:
|
|
disjoint types,
|
|
syntactic interface,
|
|
mutable fields.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
|
|
<a name="g13"></a>
|
|
|
|
<h4><br><a name="./status:h13"></a>4.3. Unicode<a name="progress:unicode"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
Informal requirements:
|
|
provision for Unicode characters and
|
|
character syntax, Unicode strings and string syntax; Unicode
|
|
character I/O; <tt>integer->char</tt> and <tt>char->integer</tt> are inverse
|
|
operations and support Unicode-specific text encodings;
|
|
write/read invariance for every datum, including symbols.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
|
|
<a name="g14"></a>
|
|
|
|
<h4><br><a name="./status:h14"></a>4.4. Arithmetic<a name="progress:arithmetic"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
Informal requirements:
|
|
support for IEEE zeros, infinities, and NaNs,
|
|
clean up behavior of <tt>eqv?</tt> wrt numbers,
|
|
fix certain arithmetic operations,
|
|
transparency.
|
|
|
|
<p>
|
|
Changes for R<sup>6</sup>RS 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.
|
|
|
|
<p>
|
|
|
|
<a name="g15"></a>
|
|
|
|
<h4><br><a name="./status:h15"></a>4.5. Exceptions<a name="progress:exceptions"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
Informal requirements:
|
|
clarify the meaning of "is an error,"
|
|
view exception handling as a means of communication between
|
|
parts of the program.
|
|
|
|
<p>
|
|
Proposals for this subsystem are currently under discussion.
|
|
No R<sup>6</sup>RS-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 R<sup>6</sup>RS exception-handling system.
|
|
|
|
<p>
|
|
|
|
<a name="g16"></a>
|
|
|
|
<h4><br><a name="./status:h16"></a>4.6. I/O<a name="progress:io"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
Informal requirements:
|
|
<tt>read-byte</tt> and <tt>write-byte</tt>,
|
|
ports that support binary I/O,
|
|
byte vectors,
|
|
block read/write operations.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Proposals for this subsystem are currently under discussion.
|
|
No R<sup>6</sup>RS-specific SRFIs have been published, and no decisions have
|
|
been made.
|
|
|
|
<p>
|
|
|
|
<a name="g17"></a>
|
|
|
|
<h4><br><a name="./status:h17"></a>4.7. Macros<a name="progress:macros"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
Informal requirements:
|
|
specify expansion semantics,
|
|
specify interaction with modules,
|
|
allow procedural transformers,
|
|
hygiene-breaking operations,
|
|
maintain support for syntax-rules.
|
|
|
|
<p>
|
|
The editors have decided to adopt <tt>syntax-case</tt> as currently
|
|
implemented in Chez Scheme and Dr. Scheme, with various differences
|
|
to be worked out by Dybvig and Flatt.
|
|
Also, the underscore identifier ("<tt>_</tt>") 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 <tt>syntax-rules</tt> pattern.
|
|
|
|
|
|
<p>
|
|
|
|
<a name="g18"></a>
|
|
|
|
<h4><br><a name="./status:h18"></a>4.8. Other possible changes<a name="progress:miscellaneous"></a></h4>
|
|
|
|
|
|
|
|
<p>
|
|
The following possible features and changes have been discussed without
|
|
resolution.
|
|
|
|
<p>
|
|
<ul>
|
|
<li>external representation for (possibly cyclic) graph structures
|
|
<li>syntax for the eof-object, if any
|
|
<li>whether <tt>#t</tt>, <tt>#f</tt>, and characters must be followed by a delimiter
|
|
<li><tt>case-lambda</tt>
|
|
<li><tt>cond-expand</tt>
|
|
<li>improving the semantics of <tt>eqv?</tt> and <tt>equal?</tt>
|
|
<li>bitwise operations on exact integers
|
|
<li>homogeneous numeric vectors
|
|
<li>support for file operations
|
|
<li>support for regular expressions
|
|
<li>support system operations
|
|
<li>formatted output
|
|
<li>making quotation of empty list optional
|
|
<li>adding support for weak pointers
|
|
<li>adding a void object to replace the "unspecified value"
|
|
<li>support for gensyms and uids
|
|
<li><tt>let-values</tt> or other multiple-value binding construct(s)
|
|
<li>R<sup>5</sup>RS compatibility library
|
|
</ul>
|
|
|
|
|
|
<p>
|
|
|
|
<a name="g19"></a>
|
|
|
|
<h3><br><a name="./status:h19"></a>5. Completion Process<a name="sect:process"></a></h3>
|
|
|
|
|
|
|
|
<p>
|
|
We intend to deliver a draft R<sup>6</sup>RS 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 R<sup>6</sup>RS by mid-June.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
<center>
|
|
<TABLE><TR><TD nowrap align="left">
|
|
<b>subsystem</b> </TD><TD nowrap align="left"> <b>primary editor</b> </TD><TD nowrap align="left"> <b>additional editors</b></TD></TR><TR><TD nowrap align="left">
|
|
libraries </TD><TD nowrap align="left"> Flatt </TD><TD nowrap align="left"> Dybvig</TD></TR><TR><TD nowrap align="left">
|
|
records </TD><TD nowrap align="left"> Sperber </TD><TD nowrap align="left"> Dybvig, van Straaten</TD></TR><TR><TD nowrap align="left">
|
|
arithmetic </TD><TD nowrap align="left"> Clinger </TD><TD nowrap align="left"> Sperber</TD></TR><TR><TD nowrap align="left">
|
|
Unicode </TD><TD nowrap align="left"> Flatt </TD><TD nowrap align="left"> Clinger</TD></TR><TR><TD nowrap align="left">
|
|
macros </TD><TD nowrap align="left"> Dybvig </TD><TD nowrap align="left"> Flatt</TD></TR><TR><TD nowrap align="left">
|
|
exceptions </TD><TD nowrap align="left"> Sperber </TD><TD nowrap align="left"> Clinger</TD></TR><TR><TD nowrap align="left">
|
|
I/O </TD><TD nowrap align="left"> Sperber </TD><TD nowrap align="left"> van Straaten</TD></TR><TR><TD nowrap align="left">
|
|
core/library split </TD><TD nowrap align="left"> van Straaten </TD><TD nowrap align="left"> Dybvig</TD></TR><TR><TD nowrap align="left">
|
|
hash tables </TD><TD nowrap align="left"> van Straaten </TD><TD nowrap align="left"> Clinger</TD></TR><TR><TD nowrap align="left">
|
|
safe/unsafe mode </TD><TD nowrap align="left"> Clinger </TD><TD nowrap align="left"> Sperber</TD></TR><TR><TD nowrap align="left">
|
|
</TD></TR></TABLE>
|
|
</center>
|
|
|
|
<p>
|
|
As time permits, we will also discuss as a group the other possible
|
|
features and changes described in Section <a href="./status-mar-2006.html#g18">4.8</a>,
|
|
as well as additional ones that may arise, and decide which are to be
|
|
incorporated into R<sup>6</sup>RS.
|
|
|
|
<p>
|
|
Responsibility for making sure that the editors complete their work and
|
|
communicate effectively lies with the chair (Dybvig) and responsibility
|
|
for creating the R<sup>6</sup>RS drafts lies with the project editor (Sperber).
|
|
|
|
<p>
|
|
|
|
|
|
</body>
|
|
</html>
|