The March 2005 R6RS Status Report
=================================
Consolidation
-------------
We have voted on a number of the decisions listed in the Revised R6RS
Status Report. Among the minor but visible decisions made are:
- the addition of multi-line and S-expression comments
- change to case-sensitive lexical syntax
- add balanced square brackets as a synonym for parentheses
- add LETREC*
- specify internal DEFINE in terms of LETREC*
- all datums will be serializable and obey read/write invariance
Unicode support
---------------
We have written up a proposal for Unicode support that defines the
notion of "char" to be a Unicode scalar value---strings are simply
vectors of these scalar values. This allows Unicode support to be
largely a conservative extension of the character and string processing
in R5RS, and avoids the API problems inherent in using a UTF-16-based
representation. Moreover, this approach has already been successfully
implemented by several Scheme implementations.
Along with Unicode support, we are also considering extensions to the
character and string literal syntax. Details are still under
discussion.
Exception Handling
------------------
An exception handling system has been proposed. Its design is based
on SRFI 34, SRFI 35, with an added condition hierarchy for bugs, in
addition to the hierarchy for errors that is part of SRFI
35. It is too early to say if this proposal will be adopted as there
are interactions with features that remain to be discussed
Numerical tower
---------------
A subcommittee was formed with a mandate to propose revisions to the
numerical tower to the whole committee. While the full proposal is
not yet finished, the subcommittee believes that sets of operations
for exact arithmetic and floating-point arithmetic should be separated
out. The subcommittee is still debating the semantics of the generic
numerical operations, and the issues connected to reading and writing
external representations of numbers.
Module System
-------------
The R6RS committee has put significant effort into the module system
issue. Some members of the committee have written strawman proposals.
However, the differences between these proposals is too large to allow
for a simple unification of the systems. We have written up a summary
with a discussion of the various issues, and how they relate to the
various proposals.
In particular, the proposed module systems all address different sets
of requirements, and hit very different spots on the design spectrum:
presently it seems at least very difficult to address all different
requirements with a single mechanism in the language.
Specifically, a module system akin to the one in Chez Scheme which is
integrated with the core language, handles the manipulation of
environments in a uniform manner, at the cost of complicating the
static semantics of the language.
On the other hand, module systems like those of PLT Scheme, Scheme 48
or Bigloo at least partly reside in a language that is separate from
the core language, thus trading simplicity and easier processing of
the module language for expressive power.
It would be nice to separate the concerns of environment manipulation
and linking, both of which are in some degree part of all the proposed
module systems. However, this is a technically difficult issue, and
we expect that significant additional effort will be needed to resolve
it. It seems probable that little progress can be made without
significant additional compromise.
Records
-------
We expect a system for defining record types to be part of R6RS, and
are exploring the design space for such systems. Two concrete
proposals have been written.
Procedural issues
-----------------
A shared CVS archive has been set up to enable work on the actual
document. We're also currently testing video-conferencing to allow
interactive discussions.