Revising R6RS #574
Comments
|
As the chair of the R7RS-large working group, I support this effort. Here are some further suggestions for base-level R6.1RS libraries along with sample proposals:
I think it's very important to standardize these things; the detailed proposals are just indicative. I only wish they were so straightforward for R7RS-large. |
|
I want to update you on this topic briefly: I asked the Scheme Steering Committee for their support for this endeavour. They will discuss the topic at their next meeting (probably by the end of October). I hope we get a positive reply. |
|
Thank you for pointing this out, @LiberalArtist. PS The Scheme Steering Committee hasn't made up their mind yet, so I cannot tell more in this direction at the moment. While Scheme does not belong to anyone, and we are free to take any action we want, it will be better if we have broad support. |
|
This is another place where a revision of R6RS can improve the standard: |
|
Another addition to the list: #835 (comment) |
|
Provided r7rs large does get finalized, why should r6rs be revised instead of adopting the former? |
There are at least the following reasons:
That said, an R6.1RS should anticipate the upcoming R7RS-large and should aim for better interoperability (compared to R6RS) where possible. |
|
Fragmentation between R6RS and R7RS has already been incredibly detrimental to Scheme. This split resulted in two competing standards and arguably contributed to languages like Racket and Gerbil becoming part of the Scheme family instead of R*RS supersets. Developing yet another incompatible standard with R6.1RS will hurt the teachability and portability of code even more. For these reasons, conserving the idiosyncrasies of R6RS is not worth the fragmentation it perpetuates. The concerns about the size and finalization time of R7RS-large can be addressed in other ways besides continuing R6RS. One approach is developing an R7RS-medium standard. This intermediate version would provide a balance between the simplicity of R7RS-small and the comprehensiveness of R7RS-large, making it more practical for current implementations to transition and adopt. |
It was R7RS that broke compatibility with the preceding standard, not R6RS. While we can regret it or blame the Steering Committee responsible for the R7RS charter, it won't change history, and we have to live with the results of this process. When you write "conserving the idiosyncrasies of R6RS", it suggests that you would let R7RS overrule R6RS in case of differences and favour R7RS in general over R6RS. In this case, the R7RS-large project is probably to your liking. There is no fundamental reason to rank R7RS above R6RS, though. In fact, many Schemers prefer the R6RS dialect, which is still ahead of R7RS in terms of precision, sophistication, and functionality. One of the most advanced RnRS implementations (if not the most advanced one) is an implementation of R6RS, not R7RS. That said, a revision to R6RS does not widen the gap to R7RS but will likely narrow it. So, the only reason that speaks against an R6.1RS is ultimately political: "There shall be only one true Scheme standard, and all Schemers shall assemble behind this one and not stray. For this, every initiative concerned with a different standard must be treated as an orphan." The problem with this maxim is that the proper scheme standard needs to be decided, i.e., whether it shall be in the tradition of R6RS or in the tradition of R7RS. The wider community does not have a consensus on the latter point. People in the R7RS subcommunity think R7RS is the better option; people in the R6RS community think R6RS is the better language. Until such a consensus is reached (R6.1RS and R7RS-large are just steps toward it), enforcing the maxim would alienate or drive away half of the combined Scheme community.
This would only solve one of my points. During my involvement with R7RS-large, I tried to lobby to base it on a subset, as you describe, which is a superset of both R6RS and R7RS-small but is neither biased towards R6RS nor R7RS-small (and is, in particular, allowed to correct R7RS-small where it went wrong). However, it was decided to base R7RS-large strictly on R7RS-small and not give R6RS and R7RS-small equal footing. This does not mean that R7RS-large will be a worse language. Maybe it becomes a better individual language with a bias towards R7RS-small. But it does mean that R7RS-large (or any R7RS-medium) won't be a successor to R6.1RS. In any case, I am not sure whether this issue tracker is the right place to discuss these political questions. It is certainly the right place to add items to the list that an R6.1RS should address because they are clearly bugs in R6RS or because they are sorely missing. An R6.1RS won't be a Scheme for every schemer, but those don't need to complain because, for them, there is R7RS-large, which won't go away because of an R6.1RS. On the contrary, should Chez Scheme support a future R6.1RS, this will likely be a better base for implementing an R7RS(-large) on top of Chez Scheme than R6RS would be. |
|
"This would only solve one of my points. During my involvement with R7RS-large, I tried to lobby to base it on a subset, as you describe, which is a superset of both R6RS and R7RS-smal" I was referring to r7rs small being a subset of r7rs big, not also of r6rs. "There is no fundamental reason to rank R7RS above R6RS, though. In fact, many Schemers prefer the R6RS dialect, which is still ahead of R7RS in terms of precision, sophistication, and functionality." Could you explain the way people think r6rs wins in terms of precision and sophistication ? R7RS small has less functionality but that is something should be addressed by developing more R7RS big and or medium . Likewise fundamental defficiencies could and should be addressed in future standards. |
I understood. What I wanted to say was that "medium"-like dialect based on both R6RS and R7RS-small without favouring R7RS-small over R6RS could have been a way forward.
Just to give a few examples: R6RS has a condition system and clearly defines where, when, and what exceptions are to be raised by the system. Contrary to this, R7RS mostly speaks of "it is an error," and its exception system is mostly useless for portable code when it comes to exceptions raised by the implementation. The R6RS is very detailed about the semantics of macro expansions of library and procedure bodies, and it has found the correct semantics so that identifier syntax can define variable-like identifiers. In contrast, the R7RS forgot this lesson. The point is not that not all of this can be added to R7RS; the point is that there is already a standardized Scheme programming language that has all these features on board and for which excellent implementations exist. It is imaginable that a language like R7RS-large would have long been finished if it were based on R6RS because this wouldn't involve reinventing many wheels. Have you done substantial programming both in R6RS and in R7RS? When I came to Scheme about 12 years ago, R7RS was about to be finalized. I was blinded by the higher version number (and probably because there was better lobbying for R7RS), so I didn't take a look at R6RS, thinking of it as an obsolete, if not obscure version (one could find a lot of FUD about R6RS). Only when I grew older and wiser 😃, did I take a look at R6RS and look into the arguments more deeply. After I had done a lot of programming in R6RS and read the report in detail, I understood that it is a better Scheme language than R7RS, not only in theory but also when it comes to practical programming. R7RS-small should have been defined as a subset of R6RS (and superset of R5RS); it could have been a language equivalent to the current R7RS-small but without introducing a split in the Scheme community. Alas, the Steering Committee of that time thought differently. Maybe we can continue this discussion somewhere else, e.g., on That said, R6RS is not perfect (only "perfect" 😉), and that's where an R6.1RS comes into play. |
|
Hi, guys, I hope the committee will concern about development environment so that the next release may be able to be easily supported. Though most schemers may mainly program in text editor, easily used language server and many other tools still confirm what those newbies experience. For example, with finned language feature supporting, these followings will be most-common-used features in real world applications:
Just taking scheme-langserver as an example, which mainly appeals users by completing local identifiers within incomplete codes, it can involve high-level rules making auto-completing much more intelligent. Especially for macros, a macro out of r6rs standard will hardly have supports and a standard macro is surely to have. |
|
Hello, I've been lurking this issue, trying to avoid saying anything. It's time to point out the elephant in the room: Two competing standards, R6RS and R7RS, is a public relations disaster. When one group ships R6RS, and another group ships R7RS, with substantial differences, it means the community has split. If the first group ships R6.1 a decade after R7, it means the split has been solidified. A solidified split means you have two languages, not one. Yet both sides of the split continue to use the name Scheme. And the core of both languages looks the same, justifying the use of the common name Scheme to refer to both. Yet the groups still go their own ways. The situation doesn't add up. Onlookers will (correctly) infer that schemers of any persuasion have no idea how to organize themselves, and will apparently spend decades working around petty disagreements instead of solving them. The following are reasonable ways to solve this problem:
I would like to emphasize the words both and agree. These words place people over concepts. Nobody wise cares at this point what any given schemer thinks about any given technical point, unless it helps achieve unity. The new standard should be called R8RS to signify that the split is history. I would strongly advise against making any other move. |
|
Lassi, please don't use this issue for political discussions. I tried to bring this point across in my latest posts here, which you, being wise 😉, surely have read. It's not that these discussions should not be had, the Chez Scheme issue tracker where possible improvements over R6RS are collected is just not the place for it. There one can also discuss whether it may even be that you want to fix something that doesn't need to be fixed. R7RS-large won't be a standard that treats R6RS on equal footing and an R8RS if it ever comes is so far in the future that it is no substitute for a small amendment like R6.1RS. |
|
An R6.1RS point release is inherently political. Point releases of any RnRS report signify deep-seated problems in the standardization process. |
|
(To clarify: Collecting improvements to R6RS is a fine thing to do, but you should be very careful about how to label and publish them.) |
R6.1RS is a tentative name. While it may not be overly pretty, it works particularly well with the R6RS library versioning and makes it clear where it stands relative to R6RS. |
|
My main point is that nobody should call any project R6.x or R7.x. Library versioning merely underscores the problem. It's a bad move if the Scheme Steering Committee ratifies minor versions. It's an even worse move if a group outside the Committee releases a "de facto" minor version of an official report. It is very important for Scheme to have cohesive authority. And it is important to project an accurate image of that authority through names and numbers. Authority is to be used sparingly and decisively. The RnRS cadence has been to ship a major version every 5-10 years. Minor versions (especially for an old edition) give the impression that the top authority in the language is either fumbling around, or there is no authority at all. |
|
Non-empty mantissa widths may need some more explanation, which can be decided upon and added to R6.1RS. See #866. |
Marc, you know that this is not true. I know you are not happy that the WG has not accepted your proposal that every Large implementation would have to support R6RS exactly as R6RS was written. (Note, though, that it has not rejected it yet either.) But we are going out of our way to try to make it possible for implementations to support R6RS, with almost all of the error handling requirements of R6RS, alongside R7RS. The R7RS steering committee has endorsed this decision. I still intend to ship as-strict-as-possible sample implementations of the Even taking ‘strict compatibility’ as strictly as possible, the only case I am aware of where it will likely not be possible (or at least not easy) for an R7RS Large implementation to signal an error where R6RS requires it is the case of unquoted vector literals, because there is no layer of the language at which a switch can be implemented for this behaviour which wouldn’t impede interoperation between libraries written for R6RS and libraries written for R7RS. Please, again, stop reinforcing the belief among R6RS people that R7RS is anti-R6RS. As I have written several times, my goal is to reunite R7RS and R6RS – the communities just as much as the technologies. I can think of no worse way to undermine this goal than the comments you keep posting here in the Chez issue tracker spreading nonsense like this. |
I think I have to clarify a number of points I made (which will hopefully show that we are closer than we are apart). The main point is that I have never meant that R7RS is anti-R6RS. The process (or the main forces behind it) that brought R7RS into existence was (were) presumably anti-R6RS, but as I have repeated several times, this is history, and we have moved forward since then. The R7RS-large project, especially under your aegis, is certainly reducing the split that was created in the post-R6RS era. However, as much as R7RS is not anti-R6RS, it is not R6RS either. While R7RS-large will likely be large enough so that it can provide an R6RS compatibility layer, this does not automatically make it a successor to R6RS. (Ignoring the known deviations, this would be roughly similar to saying that C++ is a successor to C.) It could be a successor to R6RS if R6RS got the same footing as R7RS-small in the design of the large language, and an idiomatic R6RS program would as much be an idiomatic R7RS-large program as an idiomatic R7RS-small program would be. For example, in the R7RS-large WG, I also proposed developing the Unless it has been revised recently, R7RS-large still aims for strict compatibility with R7RS-small. This is another bias towards R7RS-small vs. R6RS. If I remember correctly, at least on two occasions, discussions on questionable design decisions of R7RS-small were cancelled with reference to the goal of strict reference to R7RS-small. Technically, it is certainly the case that an R6RS compatibility layer of R7RS-large can be almost strictly compatible with R6RS. However, I do not think strict technical compatibility is the main point. Equally important points are, for example, the reintegration of pair mutation into the base library, which R6RS deprecated, and the scope and the size of the whole system. Another example is that R6RS would expect, say, Even while you try to be relatively unbiased, it cannot be denied that almost all people active on R7RS-large are firstly R7RS programmers and only secondly R6RS programmers. As far as I know, this is also true for the majority of people who have participated in previous ballots. Unless I am mistaken, all the members of the Steering Committee that participated in the vote voted against R6RS. Implementers and programmers of R6RS are basically inactive on the relevant SRFI lists or in the WG for R7RS-large. It is still possible, but unlikely, that the end result of R7RS-large would look like a natural successor of R6RS. Some people portrayed the R6.1RS proposal as an anti-R7RS-large movement. This is not the case. Instead, one of the goals of R6.1RS is to make interoperability with R7RS easier (self-evaluating vector literals are one possible example). It could become something like R7RS-large without the R7RS-small compatibility stuff and without those batteries that would not fit the size of R6RS. Moreover, R6.1RS should be rich enough so that, the other way around, a portable R7RS-large implementation on top of it should be possible. Assuming that Chez will support R6.1RS, we could then make it implement R7RS-large as well. There is certainly the possibility to develop an R6.1RS within the R7RS-large project (which could mean to basically take a subset of R7RS-large together with some refitting into the existing R6RS namespaces and possibly some additions like a The only circumstance in which the R6.1RS proposal would go against the wishes of the R7RS-large project would be if the proponents of R7RS-large insisted that future idiomatic Scheme code should abandon the tradition of R6RS (e.g., to give a trivial example, the |
By chance, I found this statement by the editors of the R6RS: [Scheme Steering Committee announcements] R6RS Released As it seems, incremental improvements were already on the editors' minds; even the name |
|
Would a revised R6RS ease interop with R7RS and succesors? It would be nice if pieces of chez scheme such as new optimization passes or backends could be written in newer standards. I gather the practicality of doing so with the current R6RS backend is somewhat controversial |
Only if those changes were backwards incompatible with things previously in r6rs, which is a bad idea.
That would imply that newer standards were somehow better. In the case of r7rs-small that is just not true. R7rs-large is still under development (i.e., it doesn't actually exist as a standard yet), but as long as it mandates strict compatibility with r7rs-small it is building on shaky foundations that none of the Chez Scheme maintainers care to invest any time to support (at least as of the last time we polled on our opinion of r7rs support). I propose (not entirely facetiously) that we instead create r8rs which admits that r7rs was a mistake and starts with a strict subset of Chez Scheme's current behavior as its baseline for what scheme should be. :) |
This is not true, at least for any reasonable definition of ‘incompatible’.
Why do you believe that R7 small is more problematic than R5RS? There is lots of undefined behaviour in R7 small, but no more so than R5RS. R7 large is building on R7 small in exactly the same way R6 built on R5. And indeed on R6 too. In fact, many of the really ‘problematic’ things with R5 (e.g. assignment to the bindings of imported identifiers) were already fixed in R7 small like they were in R6.
Guess what R7RS large is trying to do! |
Apologies for double-posting, but I would like to expand a little more on this. The R6RS editors were quite open at the time about the fact that the R6RS was not a successor to the R5RS in all respects; particularly with respect to semantics suitable for implementation by a ‘pure’ interpreter. Exempli gratia. (There were other mails to this effect posted by other editors which I can’t currently find – possibly later than that particular r6rs-discuss archive currently contains.) When those who maintain implementations which aren’t suited to full R6RS compliance got together and made something that could be called a successor to R5RS in the sense of these issues – and in so doing hewed close enough to the R6RS that they are very nearly compatible even on the level of binding names between different versions’ libraries – they get called reactionary and the spec is called nonsense. Put frankly, I don’t understand this hostility. WG1 made a few bad decisions (creating their own If Chez’s maintainers would like to wait for the large report to come out before supporting any of R7RS, that is understandable – the large report will define the R6RS compatibility provisions (e.g. what particular condition types are raised by R7RS small procedures and syntax, especially those that weren’t in R6RS, in case of errors) and it is probably better to wait than to try to second-guess what WG2 will decide and have to correct things later. But if Chez’s maintainers have rejected any form of R7RS support before even seeing the large report, simply because it will be compatible with the small report, that seems premature and unnecessarily … well, reactionary. |
|
There is no need for hostility and no need to accuse others of being hostile. We are just talking about programming language specifications. It is not up to the proponents of R7RS to lobby against other initiatives to create specifications for a Scheme language for their use, nor is it up to the proponents of non-R7RS specifications of Scheme to lobby against the R7RS-large effort. Scheme has always been inviting and open, and no group should be so cocksure of themselves to believe that their standard should also be adopted by everyone else. There will be implementations and users of R7RS as there will be implementations and users of R6.1RS. Some will like both and implement both; others will like one and won't like the other. As long as there are no deliberate obstacles to interoperability, a rich ecosystem (which includes standards) is better than a monoculture. While R7RS-large can achieve huge compatibility with R6RS, it won't be a substitute for R6RS (and R6.1RS). It will carry a lot of compatibility baggage from R7RS-small (because that part is declared sacrosanct by the Steering Committee - understandable when we recall that four of five voted against R6RS and at least one of them lobbied strongly against R6RS), forcing compromises that R6RS does not have to make. Moreover, the language, including its standard libraries, will be a lot larger than R6RS. It was voted down when I suggested that the The best outcome will be that R6.1RS will be mostly a subset of R7RS-large with its R6RS compatibility layer and that an R6RS programmer or implementation will have to make no (bad) compromises when using R6.1RS. I agree with @jltaylor-us about the R8RS comment. As described by @dpk, after fixing all the R7RS-small mistakes, R7RS-large will more or less be in the spirit of R6RS but in disguise of R7RS. It would, therefore, be more honest to drop the reference to R7RS in the language's name and admit that R7RS-small was a step back and is not a solid foundation to build a large language on top of it and that the semantics of R6RS will be used instead. In the course of that, a Steering Committee representing both communities (R6RS and R7RS) in equal measure should be selected, and joint work on R8RS should be started. The R6RS report, parts of Chez's documentation, and what @dpk has already written down for R7RS-large would be a great starting point. |
|
You are welcome to appeal to the steering committee to ask for an R8RS. I still think that merely changing the name will not change anything meaningful; that reunification of the Scheme community is the only reasonable meaningful goal of future report efforts (to the extent that it would be better to dissolve all working groups and give up on standardization, than for competing factions to continue to put out their own incompatible reports and leave users stranded in the middle of increasing compatibility headaches); and that compatibility with R7RS small and R6RS is the only technical basis on which unity of Scheme programmers who do ‘programming in the large’ can be achieved. |
+1
+1000 |
You know even better than I do how unresponsive the Steering Committee is. I asked them more than a year ago whether it would endorse an R6.1RS, but I still haven't an answer. I consider the SC (not its members, of course!) a zombie, if not dead. We, the active implementers, programmers, and users of Sscheme, should not make our decisions based on a committee that was founded in a past era and has never spoken for half of the community. It is your decision, @dpk, not the Steering Committee's, whether you put all your effort into creating a draft for a standard that follows the letter of a charter dictated by the SC or into creating a draft for a standard that does not have to consider R7RS-small higher than R6RS.
Of course, a name change alone does not change anything, but this was not the main point. "R8RS" here is a paraphrase of restarting the standardisation effort for a language that does not have to be considered the large language corresponding to R7RS-small.
I disagree. A more important goal of a report on a Scheme language is to describe a programming language (in the Scheme family) upon which implementations, programs, and further documentation can be built. The R6RS hasn't been adopted by all existing Scheme implementations since it came out, yet it serves, for example, as a foundation for the Chez Scheme programming language implemented by Chez Scheme and is used by programmers and implementers to write programs and implementations of Scheme. It would likely not make much sense for Chez Scheme to base its programming language and documentation on R7RS-large. For example, by a past poll, R7RS-large will include SRFI 125 "hash-tables" whose name and interface are incompatible with Chez's (which is based on R6RS's "hashtables"). Of course, Chez Scheme, the language, could include both APIs, but that would kill the elegance and relative minimality of the existing language. This is one reason why I have been proposing R6.1RS. From the view of R7RS-large, it may be a subset of it (and a compatibility layer); for an implementation like Chez Scheme, it will be a solid foundation for its semantics, its documentation and the actually implemented programming language. The existence of R7RS does not minimise the usefulness of R6RS, nor does R6RS minimise the usefulness of R7RS (e.g. for implementers of "toy systems"). It is your choice to give up on future report efforts, but you should not dissuade groups of Scheme implementers and programmers from formally writing down a specification on which they want to base their systems and programs and which they believe could be worth adopting by other implementers and programmers as well.
"Increasing compatibility headache" is what I would call FUD. No one who is active in any standardisation idea I know of aims for increasing incompatibilities. In fact, we have been seeing converging. Racket chose to abandon RnRS as the base of the programming language that is implemented by Racket, creating a third major Scheme language besides the existing R6RS and R7RS. It allowed Racket to venture into uncharted territory and has been, all in all, a tremendous boon for Scheme. Why would it be bad for Scheme if someone started an effort to write a standards document describing the Racket version of the Scheme language?
You are excluding the Racket programmers, for example. Or the Guile programmers, who typically use everything that Guile offers, regardless of whether it is in some RnRS. It is a misconception that Scheme programmers following different reports are unable to talk to each other or that is not possible to write code that works with different versions of the Scheme programming language. |
|
Publishing minor versions of RnRS reports is not politically astute. You are free to publish SRFI xyz: Improvements to R6RS. |
This is your personal opinion. The authors of R6RS don't seem to share it. See my earlier comment #574 (comment). I would also like to point out #574 (comment). |
|
Lassik, your comments about rnrs politics are neither helpful nor wanted. Stating your opinion the first time was ok, but repeating it after you've already been asked not to have political discussions here is just noise, so I'll be deleting any further such comments. |
|
I guess that leaves the ban. What's the hold up? |
Since its coronation in 2007, R6RS has remained a viable dialect for Scheme, both in research and for doing practical programming. The Scheme standardization process has moved on in the form of R7RS-small and a number of SRFIs for R7RS-large, but these later standards are successors of R5RS and do not supersede R6RS, so R6RS has remained frozen from its inception.
As the R6RS has been written under the assumption that it won't be the last revision in its line of dialects, I would like to explore the willingness of the community to invest in a revision of R6RS. Thanks to the library versioning system of R6RS, such a revision can be fully compatible with R6RS by using the library versions
(6 1)instead of(6)and by adding the lexical syntax#!r6.1rsanalogous to#!r6rs. (I am calling the revision 6.1 in order to signal that it does not step on the toes of R7RS but will be a successor to R6RS instead.)The goals of such a revision can be the following:
Concerning language extensions, I think the following options could be discussed:
delay-force.(srfi :nnn)of SRFI 97.syntax-case.with-ellipsisin order to be able to support the syntax-rules of SRFI 46/R7RS.includeandcond-expand(ormeta-expand) expressions.|...|and..1).What do you think? In order for such an attempt to be meaningful, it is important that the main R6RS implementations will endorse such a hypothetical R6.1RS. This includes first and foremost Chez Scheme, but also Racket should be willing to move its R6RS mode forward. We shouldn't forget about GNU Guile and the relatively new Loko either.
The first revision of R6RS does not have to be monumental. An incremental approach and relatively fast delivery seem the better choice.
Thanks!
Marc
PS Please excuse this misuse of Chez's issue tracker in order to reach an important part of the R6RS community.
The text was updated successfully, but these errors were encountered: