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. ") )
Afficher les réponses par date
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@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@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. :)
On 8/12/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Then again, we don't see symbolic algebra packages written in Scheme, we see them written in Common Lisp. :)
True, Maxima is written in CL; but I can think of at least two that are written in Scheme: there's the one Jaffer wrote (JACAL, I think); and there's Scmutils which is used in conjunction with MIT Scheme for SICM. Neither of these are written in RnRS specifically though; they are tied to particular implementations. --Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Feeley wrote:
The Scheme community will fragment and Scheme innovation will slowly die.
Are we not already fragmented? There is no agreed upon standard way to even load SRFIs. SRFI-55 [http://srfi.schemers.org/srfi-55/srfi-55.html] defines require-extension to provide this functionality. Below you will find a simple test. Note in particular that Bigloo, Gambit and MzScheme all fail to provide this functionality, just like ELK, mit-scheme and scm. Only Chicken, Gauche, Guile and stklos pass. I was under the impression that R6RS aimed to solve this problem (but I may be wrong) and I am willing to swallow whatever else has been put in if it does. Marijn Test-results of running: echo "(display \"hello world\")(newline)(require-extension (srfi 1))(display (make-list 4 'c))(newline)" | ./interpret [interpret is a custom script of mine, to help me test multiple Schemes easily] bigloo: hello world *** ERROR:eval: Unbound variable (from top-level) -- require-extension chicken: hello world (c c c c) elk: hello world begin: unbound variable: require-extension gambit: hello world *** ERROR IN (string)@1.5 -- Unbound variable: require-extension gauche: hello world (c c c c) guile: hello world (c c c c) mit-scheme: hello world ;Unbound variable: srfi ;To continue, call RESTART with an option number: ; (RESTART 3) => Specify a value to use instead of srfi. ; (RESTART 2) => Define srfi to a given value. ; (RESTART 1) => Return to read-eval-print level 1. 2 error> End of input stream reached. mzscheme: hello world reference to undefined identifier: require-extension scm: hello world ;ERROR: eval: unbound variable: require-extension ; in expression: (require-extension (srfi 1)) ; in top level environment. ; defined by eval ;STACK TRACE 1; (#@begin (#@display "hello world") (#@newline) (require-extens ... 2; ((#@thunk) (set! complete #t)) 3; ((#@require (#@quote string-port)) (#@do-thunk (#@lambda () (( ... 4; ((#@case #@option #(#<unspecified> #f #\? #\: #\n #\u #\m #\s ... 5; ((#@cond ((#@not #@*argv*) (#@set! #@*argv* (#@program-argumen ... ; program args: ("scm" "-e" "(begin (display \"hello world\")(newline)(require-extension (srfi 1))(display (make-list 4 'c))(newline) (newline))") stklos with full-syntax: hello world (c c c c) stklos: hello world (c c c c) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwCeEp/VmCx0OL2wRAv4gAJ41hlsf8YocAKsyMOcDPZgakO4ecgCgi8Ng wZAY/v+DhvvjcDHK2aA5aaM= =wyMg -----END PGP SIGNATURE-----
On 8/13/07, Marijn Schouten (hkBst) <hkBst@gentoo.org> wrote:
There is no agreed upon standard way to even load SRFIs.
This is also a problem with R6RS, in spite of the standardization of library specifications. The binding of a library identifier to actual code is *not* specified in the document. Personally, I think that is probably a correct thing (otherwise you don't really establish any real platform independence), but it does complicate the self-configuration problem. Frankly, one of the keys to writing portable code is using modularization techniques to hide the non-portable bits. I really feel that, in the current era of comprehensive IDEs and single-implementation languages, programmers are losing sight of that simple fact. SRFI-0 (and SRFI-7 which doesn't really seem to have caught on) provides that kind of core modularization primitive. I'd better step down off my R6RS soapbox *right now* :) david rush -- Once you label me, you negate me - Soren Kierkegaard
On 8/13/07, Marijn Schouten (hkBst) <hkBst@gentoo.org> wrote:
I was under the impression that R6RS aimed to solve this problem (but I may be wrong) and I am willing to swallow whatever else has been put in if it does.
To paraphrase an old wisdom attributed to Benjamin Franklin: Those who would give up essential liberty to purchase a little temporary convenience deserve neither liberty nor convenience. -- Arto Bendiken | http://bendiken.net/
Arto Bendiken wrote:
On 8/13/07, Marijn Schouten (hkBst) <hkBst@gentoo.org> wrote:
I was under the impression that R6RS aimed to solve this problem (but I may be wrong) and I am willing to swallow whatever else has been put in if it does.
To paraphrase an old wisdom attributed to Benjamin Franklin:
Those who would give up essential liberty to purchase a little temporary convenience deserve neither liberty nor convenience.
A wonderful phrase from a marvelous person, but how is it relevant to programming language theory and implementation?
At 10:13 AM 8/13/2007, M. Edward (Ed) Borasky wrote:
Arto Bendiken wrote:
On 8/13/07, Marijn Schouten (hkBst) <hkBst@gentoo.org> wrote:
I was under the impression that R6RS aimed to solve this problem (but I may be wrong) and I am willing to swallow whatever else has been put in if it does.
To paraphrase an old wisdom attributed to Benjamin Franklin:
Those who would give up essential liberty to purchase a little temporary convenience deserve neither liberty nor convenience.
A wonderful phrase from a marvelous person, but how is it relevant to programming language theory and implementation?
Let me put it this way, R5.97RS offers us a Faustian bargain: in exchange for our immortal soul (the crown jewel core of Scheme) we would receive a nice library system and set of standard libraries. And/or whatever other features you like in it. Of course deals with the Devil seldom turn out as you'd expect.... - Harold
On 13-Aug-07, at 5:42 AM, Marijn Schouten (hkBst) wrote:
Marc Feeley wrote:
The Scheme community will fragment and Scheme innovation will slowly die.
Are we not already fragmented?
I should have said "fragment more".
There is no agreed upon standard way to even load SRFIs.
SRFI-55 [http://srfi.schemers.org/srfi-55/srfi-55.html] defines require-extension to provide this functionality. Below you will find a simple test. Note in particular that Bigloo, Gambit and MzScheme all fail to provide this functionality, just like ELK, mit-scheme and scm. Only Chicken, Gauche, Guile and stklos pass. I was under the impression that R6RS aimed to solve this problem (but I may be wrong) and I am willing to swallow whatever else has been put in if it does.
You seem to believe that if R6RS is ratified, whatever it specifies will be adopted by the above Scheme implementations and that this will allow users like you to write libraries that are portable to all those implementations. But Bigloo, Chicken, Gambit, ELK, MIT-scheme, SCM and STklos will almost certainly not adopt R6RS. So currently SRFI-55 is even more portable than I expect R6RS will ever be. Note that SRFI-55 works fine with Gambit if you load syntax-case first, like this: % gsi -e '(load "~~/syntax-case")' -e '(load "srfi-55.scm")' - A simple change to the reference implementation (replacing define- syntax by define-macro) will make it work without having to load syntax-case. Marc
participants (7)
-
Arto Bendiken -
David Rush -
Harold Ancell -
Jeff Read -
M. Edward (Ed) Borasky -
Marc Feeley -
Marijn Schouten (hkBst)