1105 lines
37 KiB
HTML
1105 lines
37 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>June 21, 2006</h3>
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<table cellpadding=0 cellspacing=0>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td align="right"><b>1. </b><td><b><a class=plain href="./status-jun06.html#g0">Overview<a name="sec:overview"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td align="right"><b>2. </b><td><b><a class=plain href="./status-jun06.html#g1">Change Log</a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td align="right"><b>3. </b><td><b><a class=plain href="./status-jun06.html#g2">Guiding Principles<a name="sec:principles"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td align="right"><b>4. </b><td><b><a class=plain href="./status-jun06.html#g3">Decisions<a name="sec:decisions"></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-jun06.html#g4">Language structure<a name="sec:languagestructure"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.2. </b></td><td><b><a class=plain href="./status-jun06.html#g5">Programs<a name="sec:programs"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.3. </b></td><td><b><a class=plain href="./status-jun06.html#g6">Features eliminated<a name="sec:eliminated"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.4. </b></td><td><b><a class=plain href="./status-jun06.html#g7">Changes<a name="sec:changes"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.5. </b></td><td><b><a class=plain href="./status-jun06.html#g8">Features added<a name="sec:featuresadded"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.6. </b></td><td><b><a class=plain href="./status-jun06.html#g9">Features to be added<a name="sec:featurestobeadded"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.7. </b></td><td><b><a class=plain href="./status-jun06.html#g10">Reaffirmations<a name="sec:reaffirmations"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>4.8. </b></td><td><b><a class=plain href="./status-jun06.html#g11">Beyond R<sup>6</sup>RS<a name="sec:beyond"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
</table></td></tr>
|
||
|
|
<tr><td align="right"><b>5. </b><td><b><a class=plain href="./status-jun06.html#g12">Mutability of pairs<a name="sec:pairmutability"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td align="right"><b>6. </b><td><b><a class=plain href="./status-jun06.html#g13">Reference implementations <a name="sec:refimpl"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td align="right"><b>7. </b><td><b><a class=plain href="./status-jun06.html#g14">Work in Progress<a name="sec:workinprogres"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td></td><td><table cellpadding=0 cellspacing=0>
|
||
|
|
<tr><td><b>7.1. </b></td><td><b><a class=plain href="./status-jun06.html#g15">Libraries<a name="progress:libraries"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.2. </b></td><td><b><a class=plain href="./status-jun06.html#g16">Records<a name="progress:records"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.3. </b></td><td><b><a class=plain href="./status-jun06.html#g17">Unicode<a name="progress:unicode"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.4. </b></td><td><b><a class=plain href="./status-jun06.html#g18">Arithmetic<a name="progress:arithmetic"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.5. </b></td><td><b><a class=plain href="./status-jun06.html#g19">Exceptions<a name="progress:exceptions"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.6. </b></td><td><b><a class=plain href="./status-jun06.html#g20">I/O<a name="progress:io"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.7. </b></td><td><b><a class=plain href="./status-jun06.html#g21">Macros<a name="progress:macros"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.8. </b></td><td><b><a class=plain href="./status-jun06.html#g22">Binary block datatype<a name="progress:bytes"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<tr><td><b>7.9. </b></td><td><b><a class=plain href="./status-jun06.html#g23">Other possible changes<a name="progress:miscellaneous"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
</table></td></tr>
|
||
|
|
<tr><td align="right"><b>8. </b><td><b><a class=plain href="./status-jun06.html#g24">Completion Process<a name="sec:process"></a></a></b></td></tr>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</table>
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g0"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h0"></a>1. Overview<a name="sec: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 Revised<sup>6</sup> Report on Scheme.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g1"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h1"></a>2. Change Log</h3>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Here is a brief overview of the important changes to this document since
|
||
|
|
the <a class=ref href="status-feb06.html">February 2006</a> version.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g4">4.1</a> provides some examples of libraries
|
||
|
|
we believe might be required by R<sup>6</sup>RS.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g5">4.2</a> (new): describes the forms which portable
|
||
|
|
code can take.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g6">4.3</a>: now lists <tt>interaction-environment</tt>,
|
||
|
|
top-level definitions, and top-level expressions among the eliminated
|
||
|
|
features.
|
||
|
|
It also lists <tt>scheme-report-environment</tt>,
|
||
|
|
<tt>null-environment</tt> <tt>quotient</tt>, <tt>remainder</tt>, and
|
||
|
|
<tt>modulo</tt> among those that have been relegated to an R<sup>5</sup>RS
|
||
|
|
compatibility library.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g7">4.4</a> lists several additional changes.
|
||
|
|
(All but the first four listed are new.)
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g8">4.5</a> lists several added features.
|
||
|
|
(All but the first six listed are new.)
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g9">4.6</a> lists two new features to be
|
||
|
|
added: scripts and a byte-vector datatype.
|
||
|
|
Read/write invariance is now covered in Section <a href="./status-jun06.html#g7">4.4</a>.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g10">4.7</a> lists several newly reaffirmed features.
|
||
|
|
(All but the first three listed are new.)
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g11">4.8</a> lists several features that are officially
|
||
|
|
not under consideration for R<sup>6</sup>RS.
|
||
|
|
(All but the first four listed are new.)
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g12">5</a> 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 <tt>cons</tt> be a list.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g13">6</a> (new) describes the editors' commitment to provide
|
||
|
|
reference implementations for the major subsystems included in R<sup>6</sup>RS.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g16">7.2</a> 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.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g17">7.3</a> 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.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g18">7.4</a> documents that the arithmetic SRFI
|
||
|
|
has undergone revisions.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g19">7.5</a> documents that we have decided to base the
|
||
|
|
R<sup>6</sup>RS exception system on
|
||
|
|
SRFI's <a class=ref href="http://srfi.schemers.org/srfi-34/">34</a>
|
||
|
|
and <a class=ref href="http://srfi.schemers.org/srfi-35/">35</a>.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g20">7.6</a> documents that we have decided to base the
|
||
|
|
R<sup>6</sup>RS I/O system on
|
||
|
|
SRFI's <a class=ref href="http://srfi.schemers.org/srfi-79/">79</a>
|
||
|
|
and <a class=ref href="http://srfi.schemers.org/srfi-81/">81</a>.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g22">7.8</a> (new) documents that we have decided to
|
||
|
|
base R<sup>6</sup>RS byte vectors on
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-74/">SRFI 74</a>.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g23">7.9</a> now lists enumerations and
|
||
|
|
<tt>eval</tt> among possible features and changes.
|
||
|
|
Some of the previously listed items are no longer under consideration
|
||
|
|
and are now listed as "beyond R<sup>6</sup>RS" in Section <a href="./status-jun06.html#g11">4.8</a>:
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>external representation for (possibly cyclic) graph structures
|
||
|
|
<li>syntax for the eof-object, if any
|
||
|
|
<li><tt>cond-expand</tt>
|
||
|
|
<li>homogeneous numeric vectors
|
||
|
|
<li>support for regular expressions
|
||
|
|
<li>formatted output
|
||
|
|
<li>adding support for weak pointers
|
||
|
|
<li>support for gensyms and uids
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
One is now mentioned in Section <a href="./status-jun06.html#g4">4.1</a>:
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>R<sup>5</sup>RS compatibility library
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
One is now mentioned in Section <a href="./status-jun06.html#g10">4.7</a>:
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>making quotation of empty list optional (reaffirmed that
|
||
|
|
<tt>()</tt> is not a valid expression)
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Some are listed as changes to be made, features added, or features to be added:
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li><tt>#t</tt>, <tt>#f</tt>, and characters must be followed by a delimiter
|
||
|
|
(Section <a href="./status-jun06.html#g7">4.4</a>)
|
||
|
|
<li><tt>case-lambda</tt>
|
||
|
|
(Section <a href="./status-jun06.html#g8">4.5</a>)
|
||
|
|
<li>bitwise operations on exact integers
|
||
|
|
(Section <a href="./status-jun06.html#g18">7.4</a>)
|
||
|
|
<li>adding a void object to replace the "unspecified value"
|
||
|
|
(as "unspecified" rather than "void";
|
||
|
|
Sections <a href="./status-jun06.html#g7">4.4</a> and <a href="./status-jun06.html#g8">4.5</a>)
|
||
|
|
<li><tt>let-values</tt> or other multiple-value binding construct(s)
|
||
|
|
(both <tt>let-values</tt> and <tt>let*-values</tt>;
|
||
|
|
Section <a href="./status-jun06.html#g8">4.5</a>)
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Section <a href="./status-jun06.html#g24">8</a> now lists Sperber and Clinger as the editors
|
||
|
|
in charge of byte vectors.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g2"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h2"></a>3. Guiding Principles<a name="sec: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="g3"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h3"></a>4. Decisions<a name="sec:decisions"></a></h3>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
This section outlines the decisions made to date.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g4"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h4"></a>4.1. Language structure<a name="sec:languagestructure"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The R<sup>6</sup>RS 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.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Some examples of the kind of libraries which R6RS might specify are as
|
||
|
|
follows:
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>arithmetic-fixnum: Procedures specific to fixnums (see Section <a href="./status-jun06.html#g18">7.4</a>)
|
||
|
|
<li>arithmetic-flonum: Procedures specific to flonums (see Section <a href="./status-jun06.html#g18">7.4</a>)
|
||
|
|
<li>records-procedural: The procedural API to the record mechanism (see Section <a href="./status-jun06.html#g16">7.2</a>)
|
||
|
|
<li>records-reflection: The reflection procedures for the record mechanism (see Section <a href="./status-jun06.html#g16">7.2</a>)
|
||
|
|
<li>hash-tables: Hash tables (see Section <a href="./status-jun06.html#g9">4.6</a>)
|
||
|
|
<li>promises: <tt>delay</tt> and <tt>force</tt>
|
||
|
|
<li>eval: The <tt>eval</tt> procedure, along with necessary support procedures.
|
||
|
|
<li>r5rs: R<sup>5</sup>RS compatibility
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g5"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h5"></a>4.2. Programs<a name="sec:programs"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
R<sup>6</sup>RS 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;
|
||
|
|
R<sup>6</sup>RS has no notion of a top-level definition or expression.
|
||
|
|
The <tt>eval</tt> procedure will likely, however, allow the
|
||
|
|
evaluation of an expression (but not a definition) within the scope of a
|
||
|
|
specified set of library bindings.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g6"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h6"></a>4.3. Features eliminated<a name="sec:eliminated"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The following features of R<sup>5</sup>RS have been eliminated.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li><tt>transcript-on</tt> and <tt>transcript-off</tt>
|
||
|
|
<li><tt>interaction-environment</tt>
|
||
|
|
<li>top-level definitions and expressions (see Section <a href="./status-jun06.html#g5">4.2</a>)
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The following features of R<sup>5</sup>RS are deprecated but will be available in
|
||
|
|
an R<sup>5</sup>RS compatibility library:
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li><tt>scheme-report-environment</tt>
|
||
|
|
<li><tt>null-environment</tt>
|
||
|
|
<li><tt>quotient</tt>, <tt>remainder</tt>, <tt>modulo</tt>
|
||
|
|
(see <a class=ref href="http://srfi.schemers.org/srfi-77/">SRFI 77</a>
|
||
|
|
for replacements)
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g7"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h7"></a>4.4. Changes<a name="sec:changes"></a></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.
|
||
|
|
<li>Continuations created by <tt>begin</tt> must accept any number
|
||
|
|
of values. (This was optional in R<sup>5</sup>RS.)
|
||
|
|
<li>Any character or boolean must be followed by a delimiter.
|
||
|
|
<li>The new syntax <tt>#!r6rs</tt> is treated as a declaration that
|
||
|
|
a source library or script contains only r6rs-compatible
|
||
|
|
lexical constructs.
|
||
|
|
It is otherwise treated as a comment by the reader.
|
||
|
|
<li>An implementation may or may not signal an error when
|
||
|
|
it sees <tt>#!<i>symbol</i></tt>, for any symbol <tt><i>symbol</i></tt>
|
||
|
|
that is not <tt>r6rs</tt>.
|
||
|
|
Implementations are encouraged to use specific
|
||
|
|
<tt>#!</tt>-prefixed symbols as flags that subsequent input
|
||
|
|
contains extensions to the standard lexical syntax.
|
||
|
|
<li>All other lexical errors must be signaled, effectively
|
||
|
|
ruling out any implementation-dependent extensions unless
|
||
|
|
identified by a <tt>#!</tt>-prefixed symbol.
|
||
|
|
<li>Expressions that would have evaluated to some "unspecified value"
|
||
|
|
in R<sup>5</sup>RS evaluate to a new unique (in the sense of <tt>eq?</tt>)
|
||
|
|
"unspecified" value.
|
||
|
|
<li>Character and string comparison routines are now n-ary.
|
||
|
|
(This was optional in R<sup>5</sup>RS.)
|
||
|
|
<li>The <tt><i>in</i></tt> and <tt><i>out</i></tt> thunks of a <tt>dynamic-wind</tt> are
|
||
|
|
considered "outside" of the <tt>dynamic-wind</tt>; that is,
|
||
|
|
escaping from either does not cause the <tt><i>out</i></tt> thunk to be invoked,
|
||
|
|
and jumping back in does not cause the <tt><i>in</i></tt> thunk to be invoked.
|
||
|
|
<li>Most standard procedures are required to raise an exception with a
|
||
|
|
specific condition (in the default "safe" mode) when given
|
||
|
|
invalid inputs, except in certain specific cases where the answer
|
||
|
|
can be determined in spite of the invalid input and the additional
|
||
|
|
work involved may be extraordinary.
|
||
|
|
For example, <tt>map</tt> must raise an exception if its first argument
|
||
|
|
is not a procedure or if its other arguments are not (proper) lists
|
||
|
|
of the same length.
|
||
|
|
On the other hand, <tt>(memq <i>x</i> <i>ls</i>)</tt> must raise an
|
||
|
|
exception if and only if, before it finds a tail of <tt><i>ls</i></tt> whose
|
||
|
|
car is eq? to <tt><i>x</i></tt>, it encounters a non-list tail or cycle in
|
||
|
|
<tt><i>ls</i></tt>.
|
||
|
|
<li>When given a value <tt><i>x</i></tt> that can be represented as a datum,
|
||
|
|
<tt>write</tt> must print <tt><i>x</i></tt> as a datum for which
|
||
|
|
<tt>read</tt> would produce a value that is equivalent (in the
|
||
|
|
sense of equal?) to <tt><i>x</i></tt> (read/write invariance).
|
||
|
|
When given a value <tt><i>x</i></tt> that cannot be represented as a datum,
|
||
|
|
the behavior of <tt>write</tt> is unspecified.
|
||
|
|
<li>Every symbol, string, and character that can be created via
|
||
|
|
standard operators has at least one standard representation
|
||
|
|
as a datum.
|
||
|
|
In most implementations, this will also be true of numbers.
|
||
|
|
<li>The <tt>equal?</tt> predicate now terminates for all inputs, following
|
||
|
|
the semantics of <tt>equiv?</tt> in
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-85/">SRFI 85</a>.
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g8"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h8"></a>4.5. Features added<a name="sec:featuresadded"></a></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>symbols of the form <tt>-></tt><tt><i>subsequent</i></tt>* are now allowed
|
||
|
|
<li><tt>eof-object</tt> constructor to obtain the end-of-file object
|
||
|
|
<li><tt>unspecified</tt> procedure that returns the unspecified value
|
||
|
|
<li><tt>let-values</tt> and <tt>let*-values</tt> multiple-value binding forms
|
||
|
|
<li><tt>(define var)</tt> syntax: abbreviation for <tt>(define var (unspecified))</tt>
|
||
|
|
<li><tt>when</tt> and <tt>unless</tt> syntax
|
||
|
|
<li><tt>case-lambda</tt> syntax
|
||
|
|
<li><tt>call/cc</tt> as a second name for <tt>call-with-current-continuation</tt>
|
||
|
|
<li>new list-processing procedures (mostly inspired by
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-1/">SRFI 1</a>):
|
||
|
|
<tt>exists</tt>, <tt>forall</tt>,
|
||
|
|
<tt>fold-left</tt>, <tt>fold-right</tt>,
|
||
|
|
<tt>filter</tt>, <tt>partition</tt>,
|
||
|
|
<tt>iota</tt>,
|
||
|
|
<tt>find</tt>,
|
||
|
|
<tt>remq</tt>, <tt>remv</tt>, <tt>remove</tt>,
|
||
|
|
<tt>memp</tt>, <tt>remp</tt>, and <tt>assp</tt>
|
||
|
|
(the latter three accept a predicate and a list)
|
||
|
|
<li>Unicode support
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g9"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h9"></a>4.6. Features to be added<a name="sec:featurestobeadded"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The following features will be added, but the details have yet to be fully
|
||
|
|
worked out.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>top-level libraries
|
||
|
|
<li>exception handling
|
||
|
|
<li>safe (default) and unsafe modes
|
||
|
|
<li><tt>syntax-case</tt> macros
|
||
|
|
<li>hash tables (as a library)
|
||
|
|
<li>byte-vector datatype and operations
|
||
|
|
<li>scripts
|
||
|
|
<li>fixnum- and flonum-specific arithmetic
|
||
|
|
<li>support for infinities and NaNs
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g10"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h10"></a>4.7. Reaffirmations<a name="sec:reaffirmations"></a></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> (but see Section <a href="./status-jun06.html#g12">5</a>)
|
||
|
|
<li><tt>read-char</tt> and <tt>peek-char</tt> return the eof object
|
||
|
|
<li><tt>(begin)</tt> is still an invalid expression
|
||
|
|
<li><tt>case</tt> still uses <tt>memv</tt>
|
||
|
|
<li>one-armed <tt>if</tt> remains in the language
|
||
|
|
<li><tt>append</tt> copies all but last argument, even if last argument is <tt>()</tt>
|
||
|
|
<li><tt>()</tt> is still an invalid expression
|
||
|
|
<li>the contents of <tt>(make-string <i>n</i>)</tt> and <tt>(make-vector <i>n</i>)</tt>
|
||
|
|
remain unspecified (in particular, the elements of
|
||
|
|
<tt>(make-vector <i>n</i>)</tt> are not initialized to the new
|
||
|
|
"unspecified" value
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g11"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h11"></a>4.8. Beyond R<sup>6</sup>RS<a name="sec:beyond"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The following features are definitely not under consideration for R<sup>6</sup>RS.
|
||
|
|
We encourage anyone interested in seeing any of these features in R<sup>7</sup>RS
|
||
|
|
to make concrete proposals via the SRFI process.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>processes
|
||
|
|
<li>network programming
|
||
|
|
<li>object-oriented programming
|
||
|
|
<li>box datatype
|
||
|
|
<li>formatted output
|
||
|
|
<li>graph printing (printed representation for shared structure and cycles)
|
||
|
|
<li><tt>rec</tt> form, <tt>(rec id e) => (letrec ([id e]) id)</tt>
|
||
|
|
<li>vector-length prefix: <tt>#<i>n</i>(</tt>
|
||
|
|
<li>gensyms / uids
|
||
|
|
<li>external syntax for the eof object, e.g., <tt>#!eof</tt>
|
||
|
|
<li>external syntax for the unspecified value, e.g., <tt>#!unspecified</tt>
|
||
|
|
<li><a class=ref href="http://srfi.schemers.org/srfi-0/">SRFI 0</a> <tt>cond-expand</tt>
|
||
|
|
<li>homogeneous numeric vectors
|
||
|
|
<li>weak pointers
|
||
|
|
<li>support for regular expressions
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g12"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h12"></a>5. Mutability of pairs<a name="sec:pairmutability"></a></h3>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Although <tt>set-car!</tt> and <tt>set-cdr!</tt> were previously
|
||
|
|
reaffirmed (Section <a href="./status-jun06.html#g10">4.7</a>), the editors have decided to
|
||
|
|
reconsider whether pairs should be immutable in R<sup>6</sup>RS.
|
||
|
|
Members of the Scheme community wishing to weigh in on the issue
|
||
|
|
should contact one of the editors.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Making pairs immutable would simplify argument error checks for some
|
||
|
|
list-processing operations, simplify the <tt>list?</tt> predicate, allow
|
||
|
|
<tt>apply</tt> 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.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
A more radical change is to require that the second argument to
|
||
|
|
<tt>cons</tt> be a list, i.e., the empty list or a pair.
|
||
|
|
This would make <tt>list?</tt> 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.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g13"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h13"></a>6. Reference implementations <a name="sec:refimpl"></a></h3>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
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 R<sup>6</sup>RS, including the library, record, Unicode, arithmetic,
|
||
|
|
exceptions, I/O, and macro subsystems.
|
||
|
|
The editors may publish reference implementations of selected
|
||
|
|
additional features as well.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g14"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h14"></a>7. Work in Progress<a name="sec:workinprogres"></a></h3>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Most of the standardization effort is currently focused on several
|
||
|
|
subsystems.
|
||
|
|
Sections <a href="./status-jun06.html#g15">7.1</a>-<a href="./status-jun06.html#g22">7.8</a> list for
|
||
|
|
each subsystem any 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-jun06.html#g23">7.9</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="g15"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h15"></a>7.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
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-83/">SRFI 83</a> (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
|
||
|
|
<tt>import</tt> and <tt>export</tt> forms is tied down,
|
||
|
|
what built-in libraries besides <tt>r6rs</tt> there might
|
||
|
|
be, and how to support subsetting and supersetting of libraries.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g16"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h16"></a>7.2. Records<a name="progress:records"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Informal requirements:
|
||
|
|
disjoint types,
|
||
|
|
syntactic interface,
|
||
|
|
mutable fields.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Support for records will be based on
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-76/">SRFI 76</a> (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.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Additionally, we have decided to allow an implementation to treat any or
|
||
|
|
all of its built-in types as records, i.e., <tt>record?</tt> may or may
|
||
|
|
not return true for an object of a built-in type.
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g17"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h17"></a>7.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 will be based on
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-75/">SRFI 75</a> (R6RS Unicode
|
||
|
|
data), which has now been withdrawn as planned after revisions based in
|
||
|
|
part on community input.
|
||
|
|
See <a class=ref href="http://srfi.schemers.org/srfi-75/mail-archive/msg00309.html">http://srfi.schemers.org/srfi-75/mail-archive/msg00309.html</a>
|
||
|
|
for a discussion of probable differences between the withdrawn
|
||
|
|
SRFI and R<sup>6</sup>RS.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g18"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h18"></a>7.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, including support for fixnum-specific,
|
||
|
|
flonum-specific, and bitwise operators and IEEE arithmetic, are under
|
||
|
|
community discussion via
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-77/">SRFI 77</a> (Preliminary
|
||
|
|
Proposal for R6RS Arithmetic), which has recently been revised based in
|
||
|
|
part on community input.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g19"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h19"></a>7.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>
|
||
|
|
The editors have decided to adopt
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-34/">SRFI 34</a> (Exception Handling
|
||
|
|
for Programs) as the basis for the R<sup>6</sup>RS exception-handling system and
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-35/">SRFI 35</a> (Conditions) as the
|
||
|
|
basis for the R<sup>6</sup>RS condition system.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g20"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h20"></a>7.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-vector datatype,
|
||
|
|
block read/write operations.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The editors have decided to adopt
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-79/">SRFI 79</a> (Primitive I/O) and
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-81/">SRFI 81</a> (Port I/O) as the
|
||
|
|
basis for the R<sup>6</sup>RS I/O system.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The byte-vector datatype requirement is addressed by the binary block
|
||
|
|
datatype (Section <a href="./status-jun06.html#g22">7.8</a>).
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g21"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h21"></a>7.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 MzScheme, 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 class=ref href="http://srfi.schemers.org/srfi-93/">SRFI 93</a> (R6RS Syntax-Case
|
||
|
|
Macros) has recently been submitted.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g22"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h22"></a>7.8. Binary block datatype<a name="progress:bytes"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The editors have decided to adopt
|
||
|
|
<a class=ref href="http://srfi.schemers.org/srfi-74/">SRFI 74</a> (Octet-Addressed
|
||
|
|
Binary Blocks) as the basis for byte-vector functionality in R<sup>6</sup>RS,
|
||
|
|
with the name <tt>bytes</tt> replaces the name <tt>blob</tt>.
|
||
|
|
In contrast with the SRFI, the contents of
|
||
|
|
<tt>(make-bytes <i>n</i>)</tt> is unspecified and an
|
||
|
|
optional <tt><i>fill</i></tt> argument has been added, as
|
||
|
|
with <tt>make-string</tt> and <tt>make-vector</tt>.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g23"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h4><a name="./status-jun06:h23"></a>7.9. Other possible changes<a name="progress:miscellaneous"></a></h4>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The following possible features and changes have been discussed without
|
||
|
|
resolution.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li>improving the semantics of <tt>eqv?</tt> and <tt>equal?</tt>
|
||
|
|
<li>support for file operations
|
||
|
|
<li>support system operations
|
||
|
|
<li>support for enumerations
|
||
|
|
<li>changes to <tt>eval</tt> to reflect the existence of libraries and
|
||
|
|
other R<sup>6</sup>RS changes
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
<a name="g24"></a>
|
||
|
|
|
||
|
|
|
||
|
|
<h3><a name="./status-jun06:h24"></a>8. Completion Process<a name="sec:process"></a></h3>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<p>
|
||
|
|
We intend to deliver a draft R<sup>6</sup>RS 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.
|
||
|
|
|
||
|
|
<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">
|
||
|
|
byte vectors </TD><TD nowrap align="left"> Sperber </TD><TD nowrap align="left"> Clinger</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>
|
||
|
|
At this point, our discussions will be limited mostly to the major
|
||
|
|
subsystems and the other possible features and changes described in
|
||
|
|
Section <a href="./status-jun06.html#g23">7.9</a>.
|
||
|
|
New issues may also be considered if this can be done without
|
||
|
|
jeopardizing our goal to submit a draft R<sup>6</sup>RS to the steering
|
||
|
|
committee by the target deadline.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Responsibility for making sure that the editors complete their work and
|
||
|
|
communicate effectively lies with the chair (Dybvig) and responsibility
|
||
|
|
for completing the R<sup>6</sup>RS draft lies with the project editor (Sperber).
|
||
|
|
|
||
|
|
<p>
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|