[gambit-list] My R6RS vote

M. Edward (Ed) Borasky znmeb at cesmail.net
Mon Aug 13 00:02:42 EDT 2007


Marc Feeley wrote:
> Some of you wanted to know why I am voting against ratification of  
> the R6RS.  Here are the details.
> 
> Marc
> 
> (
> (email-address "feeley at 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.
> ")
> 
> )
> 
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> 

Thank you!! I haven't been a Schemer long enough to get a vote, but I've
been a Lispnik since the Lisp 1.5 days and it saddens me to see what
Common Lisp has bloated into without *any* of the benefits of such
bloat. We don't see web application servers written in Common Lisp, we
see them written in Java and Ruby and PHP. We don't see heavy floating
point number crunching written in Common Lisp, we see it written in
Fortran and C. We don't see embedded systems written in Common Lisp, we
see them written in C and Forth. In short, Common Lisp has taken on a
lot of baggage that Scheme hasn't, and I'd like to see Scheme stay light
and agile.

Then again, we don't see symbolic algebra packages written in Scheme, we
see them written in Common Lisp. :)



More information about the Gambit-list mailing list