johncowan
That's true, but what of it? Linus won't last forever, Linux won't last forever, computers won't last forever, and Homo sapiens won't last forever. Everything needs maintenance sooner or later. "The Rockies may crumble / Gibraltar may crumble / They're only made of clay."
Child A: I want the whole pie!
Child B: How about we split it 50/50?
Adult C: You two need to compromise. A gets 75%, B gets 25%.
(I am not implying that any particular persons are A, B, and C here.)
Committee consensus took us up through R5RS. There were about 30 members of the committee, though obviously some were more active than others. The problem with that was that we got no change except at the margins. Implementations were extended in random incompatible ways.
Then we had consensus of a small committee (5 members, later 4) for R6RS, followed by a community ratification vote. A lot of people thought the resulting standard was over-engineered, and I am quite sure that many people didn't understand all of it (I didn't for sure, especially macros and records.) Some implementers adopted it, others declared they never would.
For R7RS-small and the early stages of R7RS-large, we had the open SRFI process (anyone can propose, the community helps refine, the author decides when to freeze the result).
Now we have a (de facto) Sitzfleisch process: however stays in their seat and is still arguing the longest, wins. I eventually ran out of energy for this one.
Note that in all cases the text controls the meaning, not the author(s), and when the standard and an implementation collide, it is the implementation that is wrong. This is very nearly a sacred principle, as in C/C++ and various other multiple-implementation languages.
The main benefit of basing Racket on Chez instead of C was maintainability. A bit of performance and a few fairly unimportant features (like single floats) were lost.
1. At the REPL, if you type `T` (true), and you get back `T`, the test passes.
2. Define factorial. Then type `(/ (factorial 100) (factorial 99))`. If you get back 100, the test passes.
3. Type `(atanh -2)`. If you get a complex number, the test passes. If you get the correct complex number [namely -0.5493061443340549+1.5707963267948966i] extra credit. Far too many non-Lisp languages return NaN or throw an exception.
I do pipe stuff through various commands more or less constantly. I most often pipeline through awk, sed, sort, uniq, cat -n, etc. I have a back-burner project to write a meta-editor that works by pipelining and maintains a whole persistent undo-redo history.
By the same token, C is low-code compared to assembler, Python is low-code compared to C, and Steel Bank Common Lisp is low-code compared to Python.
And yes, I think that "The Revised Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme" is pushing the joke rather too far, but R⁷RS is what name got consensus. It's modeled on "The {,Revised|Modified} Report on the Algorithmic Language Algol 60", where the usual abbreviations were R, RR, MR, but I like to write R⁰RA60, R¹A60, R²RA60 instead. Ditto with R⁰RA68, R¹A68 for the distinct language Algol 68. Finally, the incomplete report on the Scheme offshoot Kernel is R⁻¹RK.
1) R6RS isn't really all that "batteries included", though it has some really basic features like hash tables that weren't in R5RS (but were in most Schemes anyway). The emphasis was on portability and safety. All R6RS implementations, if they don't have bugs, behave the same as all the rest at least as far as the standard extends, and the standard defines pretty closely what arguments are accepted, what values are returned, and what exceptions are signaled (the last was controversial even within the closed R6RS committee).
What wasn't considered was interoperability with common practice in other Schemes. In pursuit of this, R7RS favors interoperability over portability: the standard is less constraining, which makes it easier to integrate with existing Schemes. So R6RS hashtables (things that can be hashted, eh?) are incompatible at the procedure name level and some of the semantics with almost everybody else's hash tables. R7RS-large made them as compatible as possible. (Granted, we took more time to think about it.) R7RS-large also favors big-enough-ism over minimalism within each library, though it won't have as many libraries as people from other languages might like.
2) The current plan for R7RS-large will provide many parts of R6RS (a little bit R7RS-ified in some cases), provided they are voted in by the R7RS-large working group.
3) The rename of PLT Scheme to Racket had nothing to do with RnRS. PLT supported R6RS before and supports it R6RS today, though its use is not particularly encouraged by the Racketeers, who want you to use their own main dialect of Scheme, also called Racket. The change had more to do with PLT's multilingual capabilities: it supports many dialects of Scheme plus completely non-Scheme languages like Python and Algol 60, and it would be straightforward, if tedious, to provide Fortran, Cobol, and even C. In addition, PLT had no real link with the various university programming-language theory groups any more.
On participating in the Working Group:
Any Schemer can join the Working Group at any time: subscribe to [email protected] and listen for CFVs. (If you have never voted before on anything Scheme-related, send a message after you subscribe giving your name, a little bit about yourself, and a bit more about your interest in Scheme. This is primarily to discourage sockpuppets.) There are long spells of inactivity followed by intense discussion when a new ballot comes up. All discussions and votes are public. Behind-the-scenes work is also done in public using the SRFI process at srfi.schemers.org, which produces specs and sample
But I agree, of course, that these are not to be counted on.