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.
I think there is a wide agreement on your interpretation.
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.)
Interpreting :foo or foo: as a keyword is a question of the reader and the `read' procedure. By introducing a reader flag, say, `#!keywords' that is necessary to interpret `:foo' or `foo:' as a keyword, the charter requirements are intact.
As for adding lexical syntax like `#:foo', it will take literally less than a day to add it to any Scheme implementation, I believe. This is not what would prevent implementations to become implementations of R7RS-large. The hard things to implement are things like threads, ephemerons (done right), proper tail calls, continuations, ...
I am not saying that one should needlessly add lexical syntax, in particular, because it is (yet?) not namespaced. But if it really solves the problem at hand (and solving the keyword argument problem with special keyword lexical syntax has a long tradition), it would be unwise not to use this tool.
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.
I agree with the problem the SRFI 140 string procedures have. The base language (R7RS-small) would have to be evolved first. The approach to call immutable strings something else (like `text's) seems the best way out.
The case with "overloading lambda" is different, though. "Overloading lambda" is like adding the third argument to `member' and `assoc' as has been done in the evolution from R5RS to R7RS. Every R5RS use of `member' and `assoc' is still an R7RS use.
With our interpretation of the charter, on which we all seem to agree, we cannot extend `lambda' in a way so that
`(lambda (a b &kw c d) ...)'
with auxiliary syntax `&kw' will evaluate to a procedure taking two positional arguments and two keyword arguments `c' and `d'. The reason is that this would also be a valid procedure of R7RS-small, namely one taking five arguments irregardless to which `&kw' is bound.
On the other hand, a syntax like
`(lambda (a b (kw) c d) ...)'
would be possible. (I do not want to suggest to use this syntax; it's just an example.)
Having said this, I wouldn't think of such R7RS-small compatible syntax extensions before the end of the R7RS-large standardization process as whatever syntax extensions come up, they will also have to be compatible with each other.
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).
I can't remember whether I said this, but this doesn't mean anything. :)
We don't have to use the `#:key' syntax if we don't want to force that Chez adds a mode where `#:key' is read in our sense as long as there are letters in the alphabet. `#&key' looks equally fine. Apart from that, if Chez is the only system using `#:key' for something else, we can simply ask its author. It seems that he has already once abandoned the `#:key' syntax for uninterned symbols:
http://www.r6rs.org/r6rs-editors/2004-January/000043.html.
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.
Making string immutable by default would be a great change. Adding threads an even greater. On the other hand, making a syntax like `#&key' mandatory would take less than a day to add to any implementation. In fact, R7RS-small added some mandatory lexical syntax when compared to R5RS, which is much less straightforward to implement, namely datum labels to read and write cyclic and shared data structures. Thus, I don't see any danger here when it comes to these trivial reader extensions.
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
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xxxxxx@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CAD2gp_Q1_P1LdRBq7-NqxWU-Kpc%3DYUV9iyLKRKCWt11%3DxYZtYQ%40mail.gmail.com.