Re: Spec vs code, user-driven vs designer-driven Lassi Kortela 01 May 2021 11:01 UTC
> The smaller something is, the easier it is to add. But that's all. > > It's not too much hard work. But it won't be done unless an implementor > is willing, of course. The unfortunate thing about standards is that what wins is whatever succeeds at establishing agreement. > Many seasoned schemers dislike R6RS on aesthetic grounds to the extent > > I don't get why it could be disliked on aesthetic grounds. Probably just the scope of it, or the politics; I'm not experienced enough to know what the precise cause is, but it still ruffles feathers. > The Scheme community is split; there's no point in trying to cover it. It has been split for one third of its lifespan: about 15 years (give or take) out of 45. That's a lot, but the standard has been united twice as long as it's been split. We can unite it again. If R8RS unites R6RS and R7RS, the split will cease to have practical consequences and people will soon forget it. > What could work, is a standard that has everything from both R6RS and > R7RS-small combined, so that a Scheme implementation supporting all > features of the new standard will run all existing code from R3RS > upward. > > That would be great. It makes me very optimistic that you would support such a move! > R6RS is compatible with R5RS (to the extent it makes sense). It's hardly > irresponsible. Half of the community may see it as a bad standard but > that doesn't necessarily make it true. We come back to the unfortunate fact that successful standards establish agreement. R6RS is a successful language but an unsuccessful standard. I'm concerned that R7RS-large will meet the same fate. It's possible to design a good language that is also a good standard (i.e. reflects the consensus of the community). Scheme being in the state that it is, the only way to do that is factoring it heavily into optional features. Having options would be formalizing what Scheme implementations already do in practice anyway. No implementation supports all of R7RS, and John has mentioned that many or most of the R7RS-large libraries could be options. Scheme is also extremely well suited for subsetting; it would be nice if RnRS gave a nod to this. > I think the Python cleanup was good. But R6RS vs R5RS is not like Python > 3 vs Python 2. It would have been a good cleanup for a non-standard language. But the Python devs found out the hard way that Python 2 is a de facto standard that is not easily dethroned. R6RS is compatible with R5RS, but R6RS set future RnRS reports up to fail. A standard should never do that. The R6RS continuity plan for R7RS+ was "our way or the highway". What if it turns out the wider commmunity doesn't want all those features? Too bad for them. R7RS-large is done with the same mentality, but more measured. It's nice that the libraries are optional, but the next RnRS report has a moral obligation to carry all of the libraries that now go into it (they can be options, but they must still be there). No report should pass on a moral obligation for the next report to carry stuff that hasn't been proven and widely used in the field. Experimentation should be done via experimental design processes. > The harder part of syntax-case is the pattern matcher and hygiene. But > this is already what an R7RS-small (even an R5RS system) must ship anyway! I lack the expertise for this, but someone said psyntax (in its various forks) is basically the only extant syntax-case implementation, and only a small handful of people understand it.