R7RS small 2e

[Daphne Preston-Kendal]

I have vaguely planned to produce an R7RS small ‘second edition’ alongside the R7RS large report. The original idea was that the second edition would include only additional notes advising readers where the large language makes something more strict than the small language does, without actually changing the normative content of the small language report.

Four out of five members of the steering committee have approved, in principle, the idea that WG2 might make minor tweaks in a second edition of the small language to improve its coherence with the large language. (The fifth member was absent at that meeting.)

At the risk of opening Pandora’s box, I’d like to consider what kinds of we might tweak if we did this. I think it would be expedient to only change things that don’t require major changes on the part of implementers of the existing edition of the small language – ideally, no small language implementation should become non-conforming by these changes, so the changes should make the small language’s specification less strict, not more – and I would probably only want to make changes with the consent of WG1’s editors and any WG1 members who want to express their views.

To begin with and give a flavour of the sorts of very small tweaks we would make:

I would suggest that redefining identifiers within the ‘top level’ of a program should be made an error i.e. undefined behaviour, as it is within library and procedure bodies. This does not break existing small language implementations – their REPL-like behaviour is still allowed – but leaving this undefined allows implementations to support either the R6RS program body semantics (which will probably become the R7RS large semantics) or the original R7RS small ones.

I would also suggest that the R6RS provision allowing forms such as set!, vector-set!, etc. to return unspecified values rather than one unspecified value should be adopted into the second edition. This would not break any small language implementation, which would continue to be conformant in returning a single unspecified value, and would leave the way open for R7RS large or R8RS to potentially require zero values to be returned from these procedures.

Lastly, and probably more contentiously, a possible change would be removing the possibility of multiple ‘import’ declarations at the top of an R7RS small program. This is ambiguous in the case where one of the libraries imports an identifier called ‘import’. Since R7RS large may well define an identifier with this name (for the purpose of block-local imports) this will no longer be a theoretical issue. Existing implementations would also still be conformant in the (currently) most usual case where there is no imported identifier called ‘import’, because using an undefined identifier is undefined behaviour.

Note that none of the potential R7RS large things mentioned here have been decided on absolutely firmly yet: they’re only examples of the kinds of minor tweaks that would make it easier for us to have certain features that are on our agenda. Perhaps to avoid this turning into a flame war over these specific ideas, it would be better to immediately discuss only the question of *whether* making small tweaks of this nature in an R7RS small 2e is a good idea, and if so, how the still-active WG1 members might practically coordinate with WG2 to agree on what would be okay.


Daphne

P.S. My advice to whoever sets up R8RS working group(s): if you carry on with the small/large language split, the working groups should either work in parallel, rather than one after the other as we’ve done for R7RS, or a single working group should produce both reports.

[Alex Shinn]

Thanks Daphne,

There are two separate issues here.  The set of changes/clarifications we'd like to make, and the presentation of them (as a "2nd edition" or separate list of notes).

For the latter, I feel a separate list is more manageable and less confusing.

A second edition also seems to subvert the spirit of the small language, which is intended to be "small" in every aspect - implementation size, programmer cognitive load size, and literal size of the report.

If the Steering committee approves and a majority of WG2 members prefer a 2nd edition I'm not going to stand in the way, but recommend you first get approval from WG1 on the changes you want to make.

Regarding the initial changes you mention:

I would suggest that redefining identifiers within the ‘top level’ of a program should be made an error i.e. undefined behaviour, as it is within library and procedure bodies. This does not break existing small language implementations – their REPL-like behaviour is still allowed – but leaving this undefined allows implementations to support either the R6RS program body semantics (which will probably become the R7RS large semantics) or the original R7RS small ones.

This _does_ break compatibility with the small language and may break existing small language programs, and break the general practice of using REPL sessions and programs interchangeably.  This is a substantial change to the semantics which I recommend should not be made in the large language, much less a small language 2nd edition.  These semantics were consciously chosen and voted on, preferring R5RS compatibility, with an understanding of the changes in R6RS (related https://small.r7rs.org/ticket/112/).

I would also suggest that the R6RS provision allowing forms such as set!, vector-set!, etc. to return unspecified values rather than one unspecified value should be adopted into the second edition. This would not break any small language implementation, which would continue to be conformant in returning a single unspecified value, and would leave the way open for R7RS large or R8RS to potentially require zero values to be returned from these procedures.

This is also a breaking change (again not breaking implementations but breaking existing programs), and again something that was explicitly discussed and voted on in full awareness of the changes made by R6RS (see https://small.r7rs.org/ticket/503/).

Lastly, and probably more contentiously, a possible change would be removing the possibility of multiple ‘import’ declarations at the top of an R7RS small program.

Ironically I agree with this, but again this is something we voted on (see https://small.r7rs.org/ticket/473/).  The arguments in favor of multiple imports are the ability to interleave them from multiple expansions (include and cond-expand) and better REPL interoperability.  My personal opinion was any such logic should be encapsulated in a library, and moreover since R5RS compatibility was not an issue we should prefer R6RS compatibility (see also https://small.r7rs.org/wiki/WG1Ballot7Results/).  Either way, we can't change this in the small language now.

Regarding your general concern that WG2 is limited by decisions made in WG1, please understand that parallel progress was not really an option since most of the members overlapped anyway.  Moreover, WG1 did not proceed in ignorance of the changes in R6RS or what would likely be needed for WG2, quite the contrary we debated and voted on all of the changes in R6RS including those you mention.  Where R6RS was incompatible with R5RS we had to make a decision, and more often than not preferred R5RS which our charter recommended.

--

Alex

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg1" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/52569127-7DEE-4FFC-8788-189668187658%40nonceword.org.

[Daphne Preston-Kendal]

Thanks for your feedback, Alex.

I don’t want to comment on the specific examples I gave in detail. I’m aware that these were often deliberate decisions of WG1. The question is, if WG1 had known what WG2 would want, would you have decided differently? If you claim that you were clairvoyantly able to predict WG2’s wishes in 2025 all the way back in 2013, well, I wonder if your talent might extend to, say, stock market predictions and whether I might be able to engage your services if so ;-) In reality, WG2 has ended up being quite different than was expected while WG1 was active, both in terms of membership/participation and in terms of the decisions we’ve made.

Moreover, with the benefit of hindsight, some WG1 members know their rationales were wrong and now regret choices that could have led to a different, and better, small language report, if they’d been made differently at the time. As one example (albeit one which we certainly shouldn’t change in a hypothetical 2e), John has told me that WG1 decided for non-splicing let-syntax largely on the basis of an argument he wrote, but that argument was based on a misunderstanding and he would choose differently now he understands correctly. So WG1 knows that not every decision it made 15 years ago was the right one.

As for the philosophy of the small language, it is by relaxing restrictions and not changing them or imposing new ones that I hope the 2e would stay in the spirit of the 1e. It is true that the changes proposed are incompatible from the point of view of programs, but not from the point of view of implementations, which seems to me the far more important viewpoint for the small language’s purposes. For example, I would not propose to require zero value returns in the small language 2e, only to allow them when convenient for the implementer. (Note this is another case where the rationale for WG1’s decisions was wrong, but let’s take that to a different/future thread maybe.)

When WG1 members agree they would like a do-over; a do-over can be had without making any existing implementation non-conforming; and the change would be a real benefit to WG2’s goals — why not?

unterwegs mit Händi gesendet

entschuldige(n Sie) bitte Tippfehler und Top Posting

On 21 Jan 2025, at 03:50, Alex Shinn <alex...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPXccKpOt2tWvNQpWEG9PRczjHtyY5TW2GGOuMmB70sdg%40mail.gmail.com.

[Alex Shinn]

Hi Daphne,

As I noted in my previous email, the most active members of the two working groups overlapped, and all WG1 discussions were public and even solicited feedback from the broader community outside of WG2, so it was reasonable to assume the decisions made by WG1 were not a concern for WG2.  At least that was the decision of the WG2 chair at the time and I don't think it's productive to second guess it at this point.

What we failed to predict was not the issues themselves but the fact that WG2 would still be going 15 years later, with most members including the chair replaced.  It is quite natural that the new members are unhappy with decisions made such a long time ago.

However, although R7RS small is about as liberal as it gets in terms of standards, we do have to abide by those decisions.  Otherwise we defeat the purpose of standardization to begin with.

The small language has been in use for almost 15 years, with at least 11 implementations and countless programs.  Each of the initial changes you propose would break existing programs (I believe I have examples of all three in my own codebase).  They are not clarifications, errata or backwards compatible extensions, they are simply incompatible.  Trying to sneak these changes in with a label of "compatibility" is dishonest.

If you truly find the decisions unacceptable for WG2 then you can simply break compatibility on those points with the small language.  Please keep a list of all known incompatibilities, just as the small language lists its incompatibilities with R5RS and R7RS.  But please don't publish a 2nd edition changing only those things the WG2 members wished they could "do over" on behalf of the now defunct WG1.

Probably what you really want is to jump straight to R8RS, and I'm sympathetic with that.  Maybe the best way to achieve this is to wrap up the large language as quickly as possible.

I'm afraid I truly don't have time to help in any of this though, and my replies may be extremely delayed.

I wish you the best of luck and my heartfelt thanks for taking on this insurmountable task.

--

Alex

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/7A1A7EED-0DB9-4EAA-93D0-B30930D67EF1%40nonceword.org.