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.