r6rs


What is R6RS?

The next revision of the RnRS document that is currently in progress. See the charter document. for more information about the process. There was also a presentation at the 2004 Scheme Workshop, a paper description of which is available in the proceedings of the workshop (PDF). There is a updated status report at March 2006 Status Report.

Preliminary Report

At this time there is a preliminary report at http://www.r6rs.org. The current version is the Final R6RS (PDF). Also related to the current report is the standard libraries (PDF) , non-normative appendicies (PDF) and Rationale.

Changes in R6RS

The following are confirmed changes in the report, as of the March 2005 Status Report.

Syntax is case-sensitive

Jorgen-Schäfer

Two symbols that differ only in case should not be able to mean different things - I would consider code that uses it problematic to buggy. I also want to be able to talk about LET without being corrected that the name is let not LET.

The two arguments in favor of this are:

Unicode makes case-insensitivity more difficult - This is wrong. If R6RS allows unicode identifiers (and no one said so as of yet), each implementation will have to perform normalization anyways. Normalization turns ambiguous sequences into a single representation - e.g. accented characters can be written in two different ways in Unicode, and normalization turns that into one. Adding the case-folding rules, which exist, would be trivial. This would allow for case-folded but case-preserving symbols.

Implementations switch to case sensitive syntax - This is true, but not a good reason. The reason for this switch is XML and, sometimes, UNIX tradition. But the Scheme standard should not decide because of current hip trends in the IT industry. Syntax exists in some implementations - #cs and #ci - that allows to read special forms case-sensitively if so required. That's all we need to have XML compatibility.


Brackets: [ ] is now equivalent to ( )

Jorgen-Schäfer

This is rather annoying as well. Parens are an indentation help for your editor, and keeping alternating brackets and parens balanced is annoying (don't delete parens somewhere and add at the end - that might break the code!). This change implies that people use parens to read their code. A horrible thought. But this is easily solved by writing an Emacs conversion tool.


r2q2

I also find this annoying. Sure the justification of using this will be to clarify let's , cond's etc.. but it reduces the clarity of the language.


Multiple Return Values will stay.

(Please refer to lengthy flame wars on comp.lang.scheme, don't repeat them here.)

Jorgen-Schäfer

Yay from me!


Unspecified order of evaluation.

(Please refer to lengthy flame wars on comp.lang.scheme, don't repeat them here.)

Jorgen-Schäfer

Yay from me at least.


More escape characters in strings ("\n")

Jorgen-Schäfer

I'm not too sure about this. "\n" in a string can mean 0x0A, 0x0D or 0x0D 0x0A on different environments. This problem existed before with #\newline as well, so it could be worse.


Multiline Comments

Expression Comments

Constructor for the EOF object

Hash tables as a library

No box datatype

letrec* for internal defines

transcript-on and transcript-off gone

R6RS SRFI's

Currently there are three SRFI's that have been submitted that are currently drafts which are a part of R6RS. These SRFI's are srfi:75 (R6RS Unicode data), srfi:83 (R6RS Library Syntax) and srfi:76 (R6RS Records).

R6RS adoption

Some Scheme implementors don't intend to support R6RS, including the authors of mit-scheme?, gambit, chicken, and bigloo. (Source)

(Beware, the source is just a claim, too!)

Ratification

R6RS is up for voting; if you have strong feelings for or against it, go to http://www.r6rs.org/ratification/ (beware, voting requires that you write an 150 word essay explaining your interest in Scheme)


category-standards