| Date: Mon, 13 Aug 2007 13:34:17 -0400
| From: "Lynn Winebarger" <owinebar at gmail.com>
|
| 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.
In retrospect, voter registration should have been announced only on
r6rs-discuss at lists.r6rs.org, not on comp.lang.scheme.
| I know Will has posted his explanation. Are there any others?
Here is my "No" vote:
-=-=-=-=-
There are many flawed aspects of R5.97RS, which time does not permit
me to cover. I will describe three.
Macros
In the R5.97RS introduction:
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.
This was true of R3RS and R4RS, but not for R5RS and R5.97RS. In R3RS
and R4RS there were a small number of rules for forming expressions:
DEFINE, QUOTE, LAMBDA, IF, SET!, BEGIN, COND, AND, OR, CASE, LET,
LET*, LETREC, DO, DELAY, QUASIQUOTE, and combinations.
I have 70,000 lines of mathematical, scientific, engineering,
database, and scripting software written in (R4RS) Scheme showing that
this small number of rules is "flexible enough to support most of the
major programming paradigms in use today."
One reason that this large multi-author corpus of (free software)
Scheme code can be actively developed and maintained is because R4RS
code is very readable. In a R4RS compliant file, it is easy to see
which lists are expressions which might be evaluated; there are no new
syntactic tokens which can be mistaken for identifiers. The use of
LAMBDA in arguments to procedures establishes binding scope, no matter
what those procedures do.
The significance of this achievement by R4RS is not widely
appreciated. Procedure are sufficient to create nearly any new
features. Even new control features do not require new syntax. EVAL,
VALUES, CALL-WITH-VALUES, and DYNAMIC-WIND, added in R5RS, are all
procedures.
In the R5RS introduction:
More recently, Scheme became the first programming language to
support hygienic macros, which permit the syntax of a
block-structured language to be extended in a consistent and
reliable manner.
Extending the syntax would be desirable if Scheme's "small number of
rules" were *not* sufficient "to form a practical and efficient
programming language ...". But SLIB and other softwares show that
R4RS is sufficient.
The effect of adding macros to Scheme has been the proliferation of
mutually incomprehensible language dialects. We have seen the growth
of "convenience" macros like WHENNOT and UNLESS, use of macros as a
substitute for compiler optimization, and use of macros to avoid using
symbols as tokens. None of these uses increases the expressive power
of the language.
In a reusable software world, the use of incompatible dialects is
detrimental; it is only through documenting, publishing, and
deliberating, say in a SRFI, that new forms should be adopted into
that "very small number of rules for forming expressions".
Arrays
Computations have been organized into multidimensional arrays for over
200 years. Applications for multi-dimensional arrays are widespread
and continue to arise. Computer graphics and imaging, whether vector
or raster based, use arrays. A general-purpose computer language
without multidimensional arrays is an oxymoron.
Although multidimensional arrays are the subject of SRFI-25, SRFI-47,
SRFI-58, and SRFI-63, and portably supported by SLIB, search of
http://www.r6rs.org/r6rs-editors/ finds nothing to indicate that the
editors ever considered their inclusion in R6RS.
Can R5.97R Scheme be extended to support SRFI-63 arrays?
Libraries
SRFI-63 redefines EQUAL? to work on arrays. But in the R5.97RS module
system, a SRFI-63 library exporting EQUAL? will conflict with the RNRS
language export of the same name. Thus any import of the array
library (and there are many in SLIB) will require that EQUAL? be
excluded from the import of RNRS.
Thus the R5.97RS library mechanism fails to be modular; users must
know and exclude from modules any exported redefinitions, whether or
not they use those identifiers!
This is more than an inconvenience. R5.97RS prevents the sort of
language extensions which are a hallmark of LISPs. Consider SLIB's
COMMUTATIVE-RING module, which captures and redefines *, +, -, /, and
ZERO? to work on expressions:
(require 'commutative-ring)
(set! *ruleset* (combined-rulesets distribute* distribute/))
(define a 'a)
...
(define z 'z)
(* (+ a b) (- a b)) ==> (- (^ a 2) (^ b 2))
(require 'determinant)
(determinant '#2A((a b c) (d e f) (g h i))) ==>
(- (+ (* a e i) (* b f g) (* c d h)) (* a f h) (* b d i) (* c e g))
In R5.97RS, the DETERMINANT module bindings for *, +, -, and / would
be unaffected by the COMMUTATIVE-RING extension. Even creating a new
language binding to supplant RNRS is no help without modifying the
source code of the DETERMINANT module.
The R5.97RS library system has significantly reduced the expressive
power of Scheme; it is no longer possible to extend built-in
procedures to new types in a modular fashion.
Conclusion
The framework to extend R4RS and R5RS (through redefinition) made it
possible to provide those features that Scheme lacked in a portable
and modular fashion. R5.97RS not only lacks the multidimensional
arrays essential to my work, it has removed the means for remediation
of its deficiencies.
Received on Mon Aug 13 2007 - 22:38:14 UTC