If we use the syntax of SRFI 177 to write the specification of another SRFI (as opposed to merely using SRFI 177 to implement the other SRFI), that other SRFI will be tied to SRFI 177's syntax, won't it? (Whatever the final syntax of SRFI 177 will be.)
Yes, it would be, though there is the possibility of a post-finalization note, which we have used in similar circumstances. We can also make minor adjustments to a SRFI when we vote on it for inclusion into an R7RS-large docket, and we can vote in a replacement SRFI on a later docket, as was done with SRFI 158 (admittedly, that was completely upward-compatible).
There is a possibility that R7RS-largw will finally allow a superior syntax for keyword arguments (e.g. by "overloading" lambda or by having SRFI 88-like keywords so that we don't need the call/kw macro, etc.). Thus, there would have to be a clear way how to map one keyword system to another one.
Working groups 1 and 2 must work together to produce specifications that are consistent with one another. In particular, every implementation of the specifications produced by working group 2 must be an implementation of the specifications produced by working group 1. Every program that conforms to the specifications produced by working group 1 (and relies on no features beyond those guaranteed by those specifications) must also be a program that conforms to the specifications produced by working group 2.
This admittedly needs some reinterpretation, since it presumes the WG1 and WG2 are working concurrently rather than consecutively, which turned out not to be the case (though I was certainly thinking about them concurrently). However, I judge (as Chair) that the requirements of the second and third sentences are intact.
Of course, I am not a BDFL, and if someone requests a special ballot to override my interpretation of this provision, and it is voted in, and the Steering Committee agrees with the vote, then this can change. For this reason, I have copied xxxxxx@ on this email.
But as things stand, I do not believe that interpreting either :foo or foo: as a keyword satisfies either of the charter requirements. Using #:foo would do so, but I am very very reluctant to add *mandatory* lexical syntax to <
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/LexicalDocket.md> that must be provided and used in order to make use of a feature. (By comparison, array lexical syntax is not mandatory: you can construct an array using code, and #A(...) is only truly necessary if arrays are to appear in S-expression data.)
By the same token (and this is why I have also copied xxxxxx@ on this email), incorporating SRFI-140 into R7RS-large violates the charter requirements, in my judgment. The value of (string-set! (string-upcase (string #\a \#b \#c) 1 #\!) is defined by R7RS-small as "A!C". But in a SRFI-140 world, string-upcase returns an immutable string and so the string-set! call fails. This can be worked around by excluding string-upcase from the (srfi 140) library and importing it from (scheme char), or by importing (srfi 140 char) instead. But by the time that has been done across all libraries (not merely the R7RS-small ones, but the R7RS-large set as well), we essentially have a completely different dialect of Scheme, one that may run old code more efficiently but can longer be called R7RS. Overloading lambda to support keyword arguments has similarly pervasive effects.
Going back to #: syntax, it is not unimportant that it is used for keywords only in Racket and Kawa, whereas Chez uses it in the CL meaning for uninterned symbols. Someone, possibly Marc, said that whereas R7RS-small is about the past and the present, R7RS-large is about the future. But Scheme standardization is not only about keeping old code running; it's also about keeping old implementations working with minimal change. The Scheme community has more living implementations than any other language community, and it's clear that people prefer it this way, or they wouldn't go on writing new ones optimized for different use cases (as opposed to modifying and extending old implementations).
In my view, R6RS failed to spread to R5RS+ implementations (other than those maintained by members of the editorial committee) precisely because it demanded too much change from them. I don't want to happen to R7RS, and the evidence is that so far it has not. I'd like to keep it that way.
Comments and corrections?
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgWe want more school houses and less jails; more books and less arsenals;
more learning and less vice; more constant work and less crime; more
leisure and less greed; more justice and less revenge; in fact, more of
the opportunities to cultivate our better natures. --Samuel Gompers