Revising R6RS

[mnieper]

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.1rs analogous 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:

• Incorporate the errata from www.r6rs.org into the report.
• Add the "missing" type predicates as mentioned in Section 7.1 of Chez's user manual.
• Signal newcomers to the Scheme language that R6RS is still alive and hasn't been superseded by R7RS.
• Revive general interest.
• Reduce some incompatibilities with R7RS. Depending on where R7RS-large heads, this may make a reunification around a hypothetical R8RS possible.
• Extend the language according to experience since 2007.

Concerning language extensions, I think the following options could be discussed:

• Syntax parameters.
• Identifier properties.
• Delimited Continuations.
• Continuation Marks.
• Promises à la SRFI 155, which don't need delay-force.
• Datum labels in reader syntax.
• Optional basic threading library with specified semantics when available.
• Removal of seemingly artificial restrictions (like the order of definitions and expressions in (library) bodies).
• Standardizing the naming convention (srfi :nnn) of SRFI 97.
• Ellipsis and underscore as literals in syntax-case.
• Guile's with-ellipsis in order to be able to support the syntax-rules of SRFI 46/R7RS.
• Parameter objects as in SRFI 18/SRFI 39 with tail context guarantee of Racket.
• Adding a few POSIX-like OS-interface procedures, like accessing of environment variables as in SRFI 98.
• Add a new data structure like HAMTs to support purely functional "hash tables". (This can then be used for implementing the continuation marks from above.)
• Chez's local modules and imports and Chez's meta definitions.
• include and cond-expand (or meta-expand) expressions.
• Make pairs in rest lists immutable.
• Incorporate (some of) R7RS's lexical syntax for identifiers (including |...| 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.

[johnwcowan]

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:

1) Sockets: SRFI 106. This allows portable clients (servers are not as important) both for connecting to local servers like database engines, and for accessing Internet resources. Standardizing on a simple HTTP/HTTPS client would also be a Good Thing.

2) Standard FFI: PFFI. With this we can make Posix SRFI 170 and related proposals portable too.

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.

[mnieper]

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.

[LiberalArtist]

The behavior of / with exact 0 (see https://github.com/cisco/ChezScheme/issues/400 and https://github.com/cisco/ChezScheme/pull/773) seems worth adding to this list.

[mnieper]

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.

[mnieper]

This is another place where a revision of R6RS can improve the standard:

https://github.com/cisco/ChezScheme/blob/main/s/enum.ss#L27

[LiberalArtist]

Another addition to the list: https://github.com/cisco/ChezScheme/issues/835#issuecomment-2128166175

[GunpowderGuy]

Provided r7rs large does get finalized, why should r6rs be revised instead of adopting the former?

[mnieper]

Provided r7rs large does get finalized, why should r6rs be revised instead of adopting the former?

There are at least the following reasons:

• R7RS-large aims for strict R7RS-small compatibility, and most people working on R7RS-large come from the tradition of R7RS-small. This reflects the design of the language, and those looking for a programming language strictly compatible with R6RS (modulo bugs) will likely not find it with R7RS-large.
• Moreover, where R6RS and R7RS-small differ in style, R7RS-large will likely adopt the R7RS-small style (e.g. #uXXX prefixes instead of the more regular #vXXX prefixes of R6RS). (That said, there will be aspects where R7RS-large will be closer to R6RS than R7RS-small is.) Contrary to this, an R6.1RS will be a language in the tradition of R6RS, which has not been superseded by R7RS (in spite of the unfortunate numeric versions that suggest an ordering).
• R7RS-large is a larger language than R6RS. As much as R7RS-small is not a replacement for R7RS because of its (small) size, R7RS-large won't be a replacement because of its size (large). Not every implementation that implements R6RS will be willing to implement a much larger language.
• R7RS-large is a significant undertaking that will take a lot longer to finalize than it does to finalize an R6.1RS, especially should R7RS-large aim at the precision of the R6RS.

That said, an R6.1RS should anticipate the upcoming R7RS-large and should aim for better interoperability (compared to R6RS) where possible.

[GunpowderGuy]

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.

[mnieper]

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.

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.

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.

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.

[GunpowderGuy]

"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.

[mnieper]

"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.

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.

"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.

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 r/scheme on Reddit, so as not to clutter this issue tracker further.

That said, R6RS is not perfect (only "perfect" 😉), and that's where an R6.1RS comes into play.

[ufo5260987423]

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:

1. support SRFI 106, though I have already implement my own scoket. This plays an important role to call scheme program into micro-services business.
2. implement a timer like this, so programmers can decide the next step when sockets or other things expire.
3. bring chez's profiling procedures into r6rs, which is essential to 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.

[lassik]

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:

• Call the two languages by different names. (Racket took this approach.)
• Both camps agree to deprecate one standard and continue with the other.
• Both camps agree to merge the standards.

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.

[mnieper]

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.

[lassik]

An R6.1RS point release is inherently political.

Point releases of any RnRS report signify deep-seated problems in the standardization process.

[lassik]

(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.)

[mnieper]

(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.

[lassik]

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.

[mnieper]

Non-empty mantissa widths may need some more explanation, which can be decided upon and added to R6.1RS. See #866.

[dpk]

• R7RS-large aims for strict R7RS-small compatibility, and most people working on R7RS-large come from the tradition of R7RS-small. This reflects the design of the language, and those looking for a programming language strictly compatible with R6RS (modulo bugs) will likely not find it with R7RS-large.

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 (rnrs (6)) libraries in terms of R7RS Large (whether under the aegis of the WG, or in my own private capacity).

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.