My R6RS vote - Gambit-list

12 Aoû 2007


      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.
")
)