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
This commit is contained in:
Lassi Kortela 2023-01-24 23:13:22 +02:00
parent 63fe0cdca8
commit 0644ff84ec
1 changed files with 717 additions and 0 deletions

View File

@ -0,0 +1,717 @@
<!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&nbsp;Dybvig, Will&nbsp;Clinger, Matthew&nbsp;Flatt, Mike&nbsp;Sperber, and Anton&nbsp;van&nbsp;Straaten</h2>
<h3>February 24, 2006</h3>
<p>
<p>
<table cellpadding=0 cellspacing=0>
<tr><td align="right"><b>1.&nbsp;</b><td><b><a class=plain href="./status-feb06.html#g0">Overview<a name="sect:overview"></a></a></b></td></tr>
<tr><td align="right"><b>2.&nbsp;</b><td><b><a class=plain href="./status-feb06.html#g1">Guiding Principles<a name="sect:principles"></a></a></b></td></tr>
<tr><td align="right"><b>3.&nbsp;</b><td><b><a class=plain href="./status-feb06.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.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g3">Structural changes</a></b></td></tr>
<tr><td><b>3.2.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g4">Features eliminated</a></b></td></tr>
<tr><td><b>3.3.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g5">Changes</a></b></td></tr>
<tr><td><b>3.4.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g6">Features added</a></b></td></tr>
<tr><td><b>3.5.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g7">Features to be added<a name="featurestobeadded"></a></a></b></td></tr>
<tr><td><b>3.6.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g8">Reaffirmations</a></b></td></tr>
<tr><td><b>3.7.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g9">Beyond R<sup>6</sup>RS</a></b></td></tr>
</table></td></tr>
<tr><td align="right"><b>4.&nbsp;</b><td><b><a class=plain href="./status-feb06.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.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g11">Libraries<a name="progress:libraries"></a></a></b></td></tr>
<tr><td><b>4.2.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g12">Records<a name="progress:records"></a></a></b></td></tr>
<tr><td><b>4.3.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g13">Unicode<a name="progress:unicode"></a></a></b></td></tr>
<tr><td><b>4.4.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g14">Arithmetic<a name="progress:arithmetic"></a></a></b></td></tr>
<tr><td><b>4.5.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g15">Exceptions<a name="progress:exceptions"></a></a></b></td></tr>
<tr><td><b>4.6.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g16">I/O<a name="progress:io"></a></a></b></td></tr>
<tr><td><b>4.7.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g17">Macros<a name="progress:macros"></a></a></b></td></tr>
<tr><td><b>4.8.&nbsp;</b></td><td><b><a class=plain href="./status-feb06.html#g18">Other possible changes<a name="progress:miscellaneous"></a></a></b></td></tr>
</table></td></tr>
<tr><td align="right"><b>5.&nbsp;</b><td><b><a class=plain href="./status-feb06.html#g19">Completion Process<a name="sect:process"></a></a></b></td></tr>
</table>
<p>
<a name="g0"></a>
<h3><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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&nbsp;<a href="./status-feb06.html#g7">3.5</a>)
</ul>
<p>
<a name="g4"></a>
<h4><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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>-&gt;</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><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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&nbsp;<a href="./status-feb06.html#g11">4.1</a>-<a href="./status-feb06.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&nbsp;<a href="./status-feb06.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><a name="./status-feb06: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&nbsp;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><a name="./status-feb06: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&nbsp;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><a name="./status-feb06: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-&gt;char</tt> and <tt>char-&gt;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&nbsp;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><a name="./status-feb06: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&nbsp;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><a name="./status-feb06: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&nbsp;34 as a basis for
the R<sup>6</sup>RS exception-handling system.
<p>
<a name="g16"></a>
<h4><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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><a name="./status-feb06: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&nbsp;1,&nbsp;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&nbsp;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&nbsp;Straaten</TD></TR><TR><TD nowrap align="left">
core/library split </TD><TD nowrap align="left"> van&nbsp;Straaten </TD><TD nowrap align="left"> Dybvig</TD></TR><TR><TD nowrap align="left">
hash tables </TD><TD nowrap align="left"> van&nbsp;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&nbsp;<a href="./status-feb06.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>