Some of you wanted to know why I am voting against ratification of the R6RS. Here are the details.
Marc
( (email-address "feeley@iro.umontreal.ca")
(draft-version "5.97")
(ratify "No")
(explanation "
I am voting against ratification of the draft because the language it specifies violates some of the fundamental design goals and principles which are behind Scheme's fame and respect in the circle of programming languages. The proposed language is both too complex for the user to grasp easily and too complex to implement. One of R5RS Scheme's strengths is that it can be implemented with minimal effort, merely a few days for an experienced implementor. Because of this several implementations have come into existence whose collective features cover a wide range of niches (platform, speed, size, interoperability, debuggability, ...). Among the over 50 existing Scheme implementations I believe at most 5 will have the energy to convert to the R6RS spec, and I fear that very few in the future will have the courage to embark on developing new implementations. The Scheme community will fragment and Scheme innovation will slowly die.
It would be tedious to describe the detailed problems with the draft, and others have pointed out many of them. I will simply state some of the ones which are most obvious to me.
1) One of Scheme's strengths is its dynamic nature and in particular the ability to be used interactively through a REPL. The draft moves away from this by removing ``load'' and offering only a static linking model for programs. The draft does not explain how this affects program development and debugging using a REPL, which is the bread-and-butter of a large number of Scheme users.
2) Several features specified in the draft have been tested in existing implementations of Scheme insufficiently to warrant inclusion in the standard. Some features of the draft, such as the I/O system and records, are completely new and clearly suffer from feature creep. The standard is not the place to experiment. I do not think that R7RS can easily retract major features like these. A legitimate approach would be to use the SRFI process to introduce new features and APIs, to wait and see which SRFIs are adopted by users and implementors, and to standardize when there is a clear winner. For most features the last step could be skipped if the SRFI process was combined with a package repository in the spirit of Snow. This would remove the need for the whole ``Standard libraries'' document, and bring the language spec to a more palatable size.
3) The draft puts too much emphasis on performance. Is R5RS Scheme so slow that we need to introduce into the standard immutable variables, fields, and pairs? I am all for speed, but not at the expense of inconsistencies in the language design. Immutability hinders debugging and ``live-repair'', and goes against the basic design principles of Scheme:
Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and **restrictions** that make additional features appear necessary.
Given that the draft requires the full numeric tower and bignums, and that fixnum and flonum types have implementation dependent ranges, I see no need to require fixnum and flonum types in the standard. They should be moved to a SRFI.
4) The syntax for libraries is just too complex. Syntax-case is overkill. This is another unfortunate instance of feature creep. Scheme needs a simple module system that can be grasped easily. Scheme can live with the R5RS hygienic macros for a while still. ")
)