98 lines
3.8 KiB
Plaintext
98 lines
3.8 KiB
Plaintext
|
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.
|
||
|
|