[r6rs-discuss] One vote

From: Lynn Winebarger <owinebar>
Date: Mon, 13 Aug 2007 13:34:17 -0400

So, the official results won't be announced until August 26.
I voted no; my explanation is below. Reading the statements of the
electorate was interesting. I was surprised by how many people
believe popularity is the measure of success in a programming language and that
the passage of time is in itself sufficient reason to vote for ratification.
   I know Will has posted his explanation. Are there any others?

Lynn

 I am voting against the adoption of the R6RS draft candidate. It
mouths the words:

    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. Scheme demonstrates
    that a very small number of rules for forming expressions, with no
    restrictions on how they are composed, suffice to form a practical and
    efficient programming language that is flexible enough to support most
    of the major programming paradigms in use today.

but fails to honor them. The innovations of the draft fall into
essentially two pieces. The first is a syntax for defining and
importing identifiers from "top-level libraries". The second is
the addition, through the library mechanism, of a variety of data types
and attendant functional and/or syntactic interfaces. While both of
these are useful for general programming, I do not believe either of them
deserve a place in the Scheme language standard. Finally, the draft
utterly neglects the notions of "top-level program" and
"top-level environment", which are absolutely fundamental
to Scheme as a language and a system.

   Scheme historically embodies the implementation of the definitional
interpreters of Reynolds using the CPS transform. A major theme in
the development of Scheme and its compilation was that the inefficient
implementation of procedures in languages of the time were due to
being overly committed to particular representations of control and
environments. Reducing
the number of control constructs to one, lambda, his compiler was free
to choose any advantageous local representation of control it could
find.

  The treatment of data manipulation was minimal in the original language,
as these primitives were punted to the implementation language, MacLisp.
Steele stated in his RABBIT dissertation, "We have no new ideas to present
here on such issues, and so have avoid this area entirely." While the
subsequent revisions of the Report on Scheme have specified support for
specific data types and attendant functional interfaces, they
have also lacked support for low-level data type specification,
allowing implementations to punt such questions to "lower-level"
implementation languages. This neglect is unfortunate, as it plays
against the (efficient) metacircular definability of Scheme.

  Scheme is not so much a language in the usual sense as a commitment
to providing a certain kind of continuation semantics. This fact is evident in
R5RS's refusal to make the core syntactic keywords immutable in the
top-level environment. Regrettably, the R6RS draft candidate and its
library-driven programming model effectively abandons this concept.
Indeed, far too much
of the draft appears fixated on defining and punishing syntactic errors.

  Instead of the approach taken by the R6RS draft candidate, the
Schemey method would be to define generic mechanisms for implementing
libraries and data types. One set of candidates might be:
 * a safe way of specifying the layout of data structures down to the bit,
 * a generic way of introducing distinct namespaces into a running system and
    providing linkage into other namespaces,
 * extending the continuation model to communicating processes, and
 * defining program properties guaranteeing no dynamic memory allocation
   (similar to the tail-recursion guarantee).
Having these mechanisms in the core language would allow the efficient
implementation of the current R6RS proposal in Scheme as opposed to
requiring a separate implementation language. I do not have specifics for these
mechanisms, but then I do not believe an R6RS is necessary in the short-term.
Scheme is best understood as a challenge to efficiently implement semantics
that were thought to be inherently inefficient, and its revisions
should always add
fresh challenges.
Received on Mon Aug 13 2007 - 13:34:17 UTC