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.)
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.
On Sun, Mar 8, 2020 at 5:00 AM Marc Nieper-Wißkirchen <ma...@nieper-wisskirchen.de> wrote: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.Not according to my interpretation of <http://scheme-reports.org/2010/working-group-2-charter.html>, which says: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 scheme-reports-wg2@ 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 srfi-140@ 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 co...@ccil.org
We 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 scheme-reports-...@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.
Regarding #:key syntax - Gauche also uses it as an uninterned symbol.It is possible to add a reader/writer mode to switch interpretation; I hope I don't need to do so, but since we seem minority, I'd follow whatever everyone agree.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/CALN0JNHzTHDRkh-DmWiLfsdXzaSnboSwZewAd0kgobVLSnE%2BgA%40mail.gmail.com.
On 3/8/20 2:58 PM, John Cowan wrote:
> By the same token (and this is why I have also copied srfi-140@ on this email), incorporating SRFI-140 into R7RS-large violates the charter requirements, in my judgment.
Charter requirements are less of a concern to me that what is better for the Scheme language
and community in the long run.
> 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.
I guess it is *possible* to write a correct and meaningful program that that calls string-set!
on the result of string-upcase but I find that very hard to conceive of.
So I think the concern with breaking program is valid, but string-upcase is ulikely
to be an issue.
While breaking old programs is unfortunate, srfi-140 is the best kind of incompatibility:
Programs break cleanly (compile-time or run-time type-checking rather than wrong result or
hard-to-detect performance degradation); the fix is local and trivial (usually add a call
to string-copy); and the fixed programs work fine on older implementations.
In my limited experience after making strings by default immutable, there were very few
places I had to fix my code.
It would be helpful if someone had larger programs that use strings, and tried running
then with srfi-140 - perhaps using Kawa. I'd like to know if you had to change much,
and if it was difficult to do so.
On 3/9/20 12:42 AM, Marc Nieper-Wißkirchen wrote:
> 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.
That would be an absolute disaster. It would break *every* existing string-using program,
not in the sense of no longer working, but in the sense of using a deprecated/obsolete API,
as well as performance issues for programs that are not updated.
How do you visualize the state of Scheme if the new standard recommends text-upcase etc
in place of string-upcase etc? How will tutorials and other documents be changed? Who
will change their existing programs to use the new text-xxx APIs? My guess is almost nobody.
Either leave strings R7RS-large unchanged from R7RS-small (perhaps with a deprecation
warning), or some variant of srfi-152 (also perhaps with a deprecation warning), or
go with srfi-140 (possibly with some tweaking). srfi-135 would be a disaster, IMO.
--
--Per Bothner
p...@bothner.com http://per.bothner.com/
--
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 scheme-reports-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/7d2ae20c-2cf0-36d7-ce58-7d5ef153c1c2%40bothner.com.
> Is there any prior use of `#&key’?
That is the syntax for boxes in some Scheme systems.
Charter requirements are less of a concern to me that what is better for the Scheme language
and community in the long run.
I guess it is *possible* to write a correct and meaningful program that that calls string-set!
on the result of string-upcase but I find that very hard to conceive of.
So I think the concern with breaking program is valid, but string-upcase is ulikely
to be an issue.
In my limited experience after making strings by default immutable, there were very few
places I had to fix my code.
On 3/9/20 12:42 AM, Marc Nieper-Wißkirchen wrote:
> I agree with the problem the SRFI 140 string procedures have. The base language (R7RS-small) would have to be evolved first.
[SRFI 135] would be an absolute disaster. It would break *every* existing string-using program,
not in the sense of no longer working, but in the sense of using a deprecated/obsolete API,
as well as performance issues for programs that are not updated.
How do you visualize the state of Scheme if the new standard recommends text-upcase etc
in place of string-upcase etc?
How will tutorials and other documents be changed? Who
will change their existing programs to use the new text-xxx APIs? My guess is almost nobody.