Am Sa., 16. Mai 2020 um 20:40 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>: > I don't agree that I'm free, even with the SRFI author's consent, to add whatever I want to the SRFI. The SRFI process constrains me in ways that I consider valuable. Even where I've made refinements to the process, the idea is not to allow substantial changes to SRFIs post-finalization. Instead, the idea is to allow correction of errors and, in the case of post-finalization notes, to allow adding clarifications and recommendations — not requirements — made by the author after finalization. I didn't want to claim my understanding of what is allowed to in the SRFI process or not unduly because this is nothing I am an expert in. Thus I wrote "freely" to express that this is outside of what I can talk about. > I'm perfectly willing to believe that I've made a mistake in publishing a particular post-finalization note. In this case, I've gone over the diffs, and as far as I can see, John's note #3 doesn't change any of the requirements of the SRFI. It simply removes the recommendation that implementations that support both SRFI 116 and immutable quotations return SRFI 116 immutable quotations for quotations. Since that was a recommendation and not a requirement in the finalized text, conforming implementations were already free to ignore it, so I don't feel that I've overstepped or violated the process by accepting this note. I may also have misunderstood the recent change but without the PFN, one could implement this SRFI in a way that `pair?' returns #t exactly when `ipair?' returns #t. (Not necessarily an unreasonable implementation.) The new PFN, however, reads in the first paragraph under Quotation: "However, such pairs are the same type as mutable pairs: they answer #t to pair? and #f to ipair?." [...] >> While a PFN may not be normative, some implementations will now >> provide the old semantics under the SRFI 116 name, other >> implementations will provide the new semantics. That worse than just >> one semantics. > > > Unfortunately, even before this PFN, that was already the case, again because the removed text was a recommendation, not a requirement, of the SRFI. Right, this only narrows implementations. > A SRFI that is more emphatic (i.e. says "must" vs. "should" or "recommends") would be an excellent idea. If we get the semantics right and so that they will be easy and natural to use. > I hope that you will forgive me if I've made an error in judgment here. I'm trying hard to follow the process and to make it as effective and practical as possible, but it's alarmingly difficult to get it right sometimes. I think (and I hope) that no one blames anyone! We all do this in our spare time and programming languages and their specifications are a complex matter. Actually, you always amaze me, Arthur, about the many different SRFIs you have to keep in your head and which you have to understand. I, on the other side, have the freedom to pick the SRFIs I would like to contribute to. Marc
