R7RS

What do you think so far? It's way smaller than R6RS.

I have not looked at it yet, but thanks for bringing the good news.  I hope it is as small as R5RS, and as readable.  R6RS actually made me fall asleep, twice.

If its smaller does that mean scheme is no longer backwards compatible with past releases?

who can find these language definitions readable?

>>3
``Backwards compatibility'' is a Jewish ENTERPRISE concept invented to cage your creativity. Real languages don't do that.

>>3
I've not read any of the R7RS drafts yet, but I've heard that it's supposed to be backwards compatible with R5RS... They're basically pretending R6RS never happened.

>>5
Go away.

>>3,6

Not quite. R7RS will have two specifications. The small language specification which will be the spiritual successor to R5RS. And then the large language specification which will actually be a little bigger than R6RS in terms of libraries (they're standardizing modules/namespaces and a few other things).

The small language specification will be a proper subset of the large language specification.

>>8
why two?

>>9
Because you obviously don't need three to accomplish both tasks.

R⁴RS was where things needed to take a break. It was a very good standard. The community today is pointlessly fractured. They were already fractured in the sense that the base language described by the standard was insufficient in everyone's eyes, so each distribution sort of did its own thing. But that's always going to be true. The alternative is plain to see: java or C++, which are garbage by comparison. Keeping a small base language like scheme attempted to ensures the survival of the language in the face of fads. Scheme is like C in this regard, simply unkillable.

I am not sure what benefit the R⁷RS split is going to bring. But I hope for the best for one of my favorite languages.

>>11
But Java collects its garbage and C++ programmers don't generate any.

>>12
Just go back to /g/. You legion needs your reinforcements.

>>11
I've always been a proponent of keeping things useful. Some people liked Scheme because it was minimalist. R7RS caters to two distinct groups, the minimalists and everyone else. IMO, the minimalists will end up reimplementing everything in the full language.

>>14
Oh for sure they will. But in what way? There seems to be significant disagreement between the various implementers about how the side issues should get done, even if they agree that "something" should be done. Which is exactly why R6RS caused the problems it did. 

But in my view as a user, not someone making a scheme distribution, that's the SRFIs solved (mostly). Making a come one come all standard would be fine if we needed portable scheme. Do we really need portable scheme?

I just use Racket anyway!

>>15
Do we really need a portable scheme?
Yes. There should at least be a proper ordering of language features so that the more minimal implementations are proper subsets and completely compatible with the larger ones. And every implementation should have the exact same syntax for a single module system. Granted it's hard to do this when one scheme implementation compiles to c and doesn't support eval, while another scheme implementation compiles to javascript and has no concept of modules, and another has continuations but no big nums, and another has big nums but no continuations, etc.
 
I just use Racket anyway!
Racket is shit.

>>16
There should at least be a proper ordering of language features so that the more minimal implementations are proper subsets and completely compatible with the larger ones.
What for? What do you gain with this? It seems entirely more practical to just port your favorite distribution than it is to try and get the community to agree on something for dubious benefits.

Granted it's hard to do this
Exactly. And it's how it should be for a small, powerful language. It's there for experimentation. If you want a fuckhuge sexp language just use CL. Scheme distributions are there for your applications. They'll have modules and srfis and libraries of other stuff and et cetera.

>>17
And if one has a library which the other lacks, you'll have to go through the effort of porting it, if at all possible.

I'd rather see these guy try and make a usable standard instead.

The new spec, however, is quite big, at 80 pages, and has some stuff which is frankly superfluous, like the case syntax.

it's still not up to par with javascript

>>19
Oh look, the kike is back.

>>17
What for? What do you gain with this?
Obviously, so that code written for the minimal implementations will be usable by the larger implementations. Libraries written for minimal scheme implementations will just work for all greater language levels. When the only thing stopping it is a consistent module system, there is really no excuse for not having this.

Second paragraph, too mad to copy
A language can be both small and portable. If the srfis and libraries have universal semantics and usage, then they will work everywhere. A collection of independent and incompatible experiments wont add up to anything, but a collection of modular experiments that may be combined together in any which way will.

>>14,17
The small language is meant for educators, students, and hobbyists wishing to learn programming or wanting to learn how to develop a minimalist Scheme compiler/interpreter.

The big language is meant for people who want to use a comprehensive Scheme for real world projects.

>>22
I see. Those are sensible reasons for why there are two Schemes.

>>21
Obviously, so that code written for the minimal implementations will be usable by the larger implementations.
I know this is obvious from what you wrote but it is not obvious from a real world perspective. In the real world I'm going to do things that simply aren't in the spec. Portable code is the most massive eschatological myth ever devised, and it is a religion whose followers should be listened to only at one's own peril. But I guess this is because my own focus is on interacting with the real world and the real world isn't portable. I understand a lot of people just write code to run on Linux and Windows and consider this ``portable'' if it can draw the same shapes on the screen. (Or to run on different Linuses and consider that portable under the same criterion.)

>>22
The small language is meant for educators, students, and hobbyists wishing to learn programming or wanting to learn how to develop a minimalist Scheme compiler/interpreter.
What part of R⁴RS is insufficient for this purpose?

The big language is meant for people who want to use a comprehensive Scheme for real world projects.
Even the massive pile of shit that is C++ is not comprehensive enough for the real world. The Scheme steering committee will surely never make it. But particular distributions can.

>>24
You are confusing platform specific compatibility with language level compatibility. The schemes and lisps have to deal with language level compatibility, something that nearly no mainstream languages have to deal with. Platform specific code can be located, isolated, and then swapped out with different implementations. If you don't have a cross platform library to get your features on your n target platforms, one way to do it is implement your needed features on each platform using a consistent interface. Then your main project only uses this single interface, and can blindly use each of the supported platforms.

But language level compatibility is another story. The differences do not correlate with a small number of features. The language level differences are present in every piece of code you write. There is no way you can feasibly manage this and your only choice is to reimplement the entire project in each target language. Nobody that's sane would consider doing this, which is why no one sane uses lisp or scheme for anything important.

C++ might be a shit language, but it isn't the language that makes it useful in the real world. The language is tolerable, but more importantly it has the ability to leverage the libraries that are already written in C++ or C. The problem with scheme is that without a consistent language, you can't begin to have libraries.