More changes coming in R⁶RS

The editorial committee charged with preparing the next version of the language definition for Scheme produced another status report on June 21. The committee is now proposing some fairly significant changes beyond those announced in the March status report; highlights follow. They are also considering (not yet proposing) an extremely radical change, which I'll discuss at the end -- skip ahead to the last three paragraphs whenever you get tired of the small stuff.

First, then, here are some of the new features and language changes that the committee endorses and will propose:

• The “top level,” as a language construct with special rules for the elaboration of definitions, will be abolished. A Scheme program will be a library (= module), i.e., a single expression. The syntax for library-expressions apparently isn't settled yet, but there will be clauses for importing variable and keyword bindings from other libraries and exporting them for the use of other libraries, as well as internal definitions, commands, and expressions. The semantics of the read-evaluate-print loop, and indeed the very existence of an interactive interface, will apparently be left completely to the ingenuity and discretion of the implementer.

• It will be possible to convert a Scheme library into an executable script in a standard way, by prepending an appropriate header.

• The quotient, remainder, and modulo procedures will be deprecated and provided only in a backwards-compatibility library. They will be replaced by div and mod procedures, with semantics similar to quotient and modulo, but extended to all real arguments (except that the divisor must be nonzero). There will be a div+mod procedure that returns both the quotient and modulo results -- Scheme's first multiple-values-returning procedure other than the values procedure itself.

• A richer mechanism for extending Scheme's syntax will be added -- essentially, R. Kent Dybvig's syntax-case mechanism. It will be roughly as described in Scheme Request for Implementation 93. The transformers can be considerably more complicated than those provided by R⁵RS syntax-rules expressions.

• There will be when- and unless-expressions -- in effect, one-sided if-expressions, with a test and any number of actions as subexpressions.

• There will be many more higher-order primitive procedures: exists (= any?), forall (= every?), fold-left, fold-right, filter, partition, find (= return the first element of a given list that satisfies a given unary predicate, or #f if none does), memp (like memq, but with a specified predicate in place of eq?), assp (similarly like assq), remp (= construct and return a list of the elements of a given list that do not bear a given relation to a given value).

• There will be several new primitive procedures related to lists, including iota, remq, remv, and remove.

• There will be an incredible number of new arithmetic procedures for dealing specifically with fixnums, floating-point numbers, exact numbers, and inexact numbers. I hope and expect that these will all be packed away in special-purpose libraries. See Scheme Request for Implementation 77 for details.

• Expressions that are described in R⁵RS as having unspecified values (assignments, calls to the display procedure, (if #f #f), and such like), will under R⁶RS all have the same value, a single value of a new type, unrelated to the empty list, #f, the eof-object, the empty vector, or any other previously required Scheme value. To ensure maximum confusion, the authors refer to this new value as “the unspecified value.” There will even be a primitive nullary procedure, unspecified, that programmers can use to generate it as needed. (I know, I know. I'm so not looking forward to teaching this.)

  Note, however, that one-argument calls to make-vector and make-string will still return structures whose elements are unspecified in the adjectival sense, i.e., the value of (vector-ref (make-vector 100) 39) may be the empty list, or #f, or 0, or some other value, as the implementor prefers -- it need not be the new “unspecified” value.

• Definitions of the form ‘(define var)’ will be permitted; storage will be allocated for var and initialized to the new “unspecified” value.

• Promises (delay-expressions and the force procedure) will be relegated to a library.

• The semantics of eval will change again. The environment data type used in calls to eval under R⁵RS will be relegated to a backwards-compatibility library. Instead, eval will evaluate its datum relative to a set of libraries specified by the caller. The datum will be required to have the form of an expression -- eval will not be required to do anything sensible with a datum that has the form of a definition.

• Binary input/output will be supported.

Now for the radical change that the authors are considering: making pairs immutable (i.e., abolishing set-car! and set-cdr!). The idea is to enable both implementers and programmers to code many common operations and primitives more simply and more efficiently and to provide better detection and reporting of errors. Any program that currently uses mutable pairs would have to be rewritten to use a programmer-defined record type instead (or even a two-element vector).

The authors are even considering the further step of requiring that second argument to the cons procedure be a list. Woo-hoo! No more dotted pairs!

Making pairs immutable would break so much existing Scheme code that I find it difficult to believe that this change will ever be adopted, but it is now on the table.