| Date: Mon, 13 Aug 2007 13:34:17 -0400 | From: "Lynn Winebarger" <[EMAIL PROTECTED]> | | 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 [email protected], 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. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
