About time. I hope it isn't another decade before R7RS.
A lot of people are complaining because R6 is so much bigger than R5. While a clean, tiny spec is a beautiful thing, it is empirically not a recipe for being able to get real work done without compromising portability. If you care about minimalism more than you care about that kind of portability, R5RS isn't going anywhere. This isn't Windows; there's no end-of-life schedule that's going to force you to upgrade.
My gripe about R6RS is that it doesn't go far enough: any sufficiently large project is still going to require non-portable extensions. But it's a leap in the right direction and we've been waiting long enough. As long as we'll eventually see an R7RS, I'm glad this revision was ratified.
The question might be, "Was R6RS ratified simply because a change is needed or because R6RS is the correct solution?"
On the comments, one of the very first complaints is that R6RS's library system is still inadequate. That seems like a grave sign for any programming language. As far as I can tell, all popular languages have a well-defined library system and popular frameworks have a well-defined plugin system, so needless hassles in terms of crafting those will only dampen popularity.
I think they should hold out to R5.98RS personally, fix a few more of the things that people complain about and perhaps hit 75 YES votes. There's obviously still room for improvement.
If you care about minimalism more than you care about that kind of portability, R5RS isn't going anywhere.
If you care about that kind of portability more than you care about excellent design and the consensus (as opposed to majority) that has made Scheme what it is, then Common Lisp isn't going anywhere.
This divisive thread is distressing to me. As someone who struggles every year or two to preserve Scheme as a development language inside a medium-size company, I think it works much better to view CL and Scheme as a family of languages used in both industry and academia. Squabbling between the camps makes both look smaller. In reality, you can often draw on CL people to do Scheme work and vice-versa.
I think he's talking about some CL bashing implicit in our discussion. My intention was not to diss CL, just to say that it represents a different design philosophy that is somehow antagonistic to what's been the tradition in Scheme. Portability, practicality and completeness over minimalism, beauty, and perfectionism (within reasonable limits; there are some practical compromises in Scheme too). Both approaches have their advantages and their (overlapping) audiences.
Now the RnRS name has been hijacked to refer to a totally different process, and by extension an attempt has been made to hijack the name Scheme for something that is a whole new Lisp dialect. I think the RnRS name has lost credibility, and I don't think the appropriation of the name Scheme will be successful. You'll hear the name Common Scheme a lot from now on.
So no, it's not the same camp anymore. Enjoy your PLT, Chez, Larceny, or Scheme48, and best of lucks.
Can you answer this: Do people call Scheme a dialect of Lisp? I know often its spoken that way. But as an active (and avid?) user of scheme is it wrong to call it "a lisp"? Or when people say Lisp do they really mean CL (other then in academic circles)?
No, it is not wrong at all. In the SICP video lectures they call it just Lisp all of the time.
It's true that when someone says Lisp they often mean CL. If it's important for you to highlight that you are talking about the family of languages, you may say "the Lisps" or "a Lisp". But just Lisp should be okay too.
Good to know. Yes I love the SICP videos and noticed that - but then they were done in the 80's, wasn't sure if things had changed somewhat since then.
In my limited exploration, I always though CL was showing its age, yet scheme seemed more "timeless" - if you can say that about programming languages.
There are certainly good ideas in CL that can help Scheme. Many of the differences are a matter of taste. For those who like small languages, R4RS isn't going away.
But any newcomer will consider the most recent version the default, and assume the others are obsolete. In other languages you seldom ever have a reason to start with an older standard unless you have legacy code to maintain. And that is the reason why they called the whole scam R6RS.
A lot of people are complaining because R6 is so much bigger than R5. While a clean, tiny spec is a beautiful thing, it is empirically not a recipe for being able to get real work done without compromising portability. If you care about minimalism more than you care about that kind of portability, R5RS isn't going anywhere. This isn't Windows; there's no end-of-life schedule that's going to force you to upgrade.
My gripe about R6RS is that it doesn't go far enough: any sufficiently large project is still going to require non-portable extensions. But it's a leap in the right direction and we've been waiting long enough. As long as we'll eventually see an R7RS, I'm glad this revision was ratified.