Final SRFI 228: Composing Comparators

Scheme Request for Implementation 228, "Composing Comparators", by Daphne Preston-Kendal, has gone into *final* status. The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-228/. Here's the abstract: Further procedures for defining SRFI 128

Re: SRFI 228 final read-through

On Sat, Dec 10, 2022 at 2:12 PM Daphne Preston-Kendal wrote: > I think the prose is fine as it is. The claim is qualified by a ‘usually’. > Perhaps ‘often’ would be a more appropriate qualifier – I’d accept that. > Okay, I've made the change to "often," and have added the sentence you recommend

Re: SRFI 228 final read-through

I am the author of this SRFI and would prefer that the mailing list for this SRFI remain on-topic: discussing matters specifically related to this SRFI. Your wish is my command. I’m well aware of the objections you’ve made elsewhere. I don’t agree with them, but I also don’t object to you di

Re: SRFI 228 final read-through

On 10 Dec 2022, at 23:03, Arthur A. Gleckler wrote: > Daphne, what do you think? We could change "personal names are usually..." > to "personal names in most Western cultures are usually...," or we could use > "personal names are often…." Given the actual example appears to talk about someone

Re: SRFI 228 final read-through

On 10 Dec 2022, at 22:46, Lassi Kortela wrote: >> I strongly disagree and would like to politely request that you not use the >> mailing list for this SRFI to discuss your views on the issue of the SRFI >> process in general. > > I'm afraid I don't respect your sentiment. I've spared no effort

Re: SRFI 228 final read-through

On Sat, Dec 10, 2022 at 1:29 PM John Cowan wrote: > I don't think the clarification actually clarifies the matter. What does > "built in" mean? Chibi's SRFI 128 library includes the SRFI 162 > identifiers, but they are "built in" only in the sense that they are > shipped with Chibi. I prefer

Re: SRFI 228 final read-through

I strongly disagree and would like to politely request that you not use the mailing list for this SRFI to discuss your views on the issue of the SRFI process in general. I'm afraid I don't respect your sentiment. I've spared no effort to help the process and the result is incomprehension and

Re: SRFI 228 final read-through

On Sat, Dec 10, 2022 at 1:55 PM Arthur A. Gleckler wrote: On Sat, Dec 10, 2022 at 10:48 AM Daphne Preston-Kendal > wrote: > > >> That was the original intention of that paragraph. >> > > Would it be reasonable to add the clarification I described? I want to > make absolutely sure that there's n

Re: SRFI 228 final read-through

On 10 Dec 2022, at 21:56, Lassi Kortela wrote: > It's confusing if an SRFI exports identifiers that are not defined in the > text of some other SRFI. > > I sympathize with the desire to have more convenient libraries to import, > instead of importing a whole bundle of SRFIs. But this is IMHO a

Re: SRFI 228 final read-through

Why can´t we simply specify that SRFI 228's library includes all exports from SRFI 128, 162, and those defined in the SRFI 228 spec? As a byproduct, this way, SRFI 228 can clean up the situation about SRFI 128/162. It's confusing if an SRFI exports identifiers that are not defined in the text o

Re: SRFI 228 final read-through

Why can´t we simply specify that SRFI 228's library includes all exports from SRFI 128, 162, and those defined in the SRFI 228 spec? As a byproduct, this way, SRFI 228 can clean up the situation about SRFI 128/162. Am Sa., 10. Dez. 2022 um 21:46 Uhr schrieb Lassi Kortela : > > NB: "rather than bei

Re: SRFI 228 final read-through

NB: "rather than being in a separate library" is especially ambiguous; does it suggest that if and when the procedures ship in some other library, the (srfi 228) library should be retroactively removed from the relevant Scheme implementations?

Re: SRFI 228 final read-through

Would it be reasonable to add the clarification I described? This wording is ambiguous: "they will simply be added to the existing comparator libraries of RnRSes and Scheme implementations, rather than being in a separate library". It's not clear what "adding to a library" and "being in a

Re: SRFI 228 final read-through

On Sat, Dec 10, 2022 at 10:48 AM Daphne Preston-Kendal wrote: > That was the original intention of that paragraph. > Would it be reasonable to add the clarification I described? I want to make absolutely sure that there's no question about retroactively redefining old APIs. People were very u

Re: SRFI 228 final read-through

On 10 Dec 2022, at 19:44, Arthur A. Gleckler wrote: > What's the right way to solve this problem? Would it be reasonable to add a > sentence saying that this paragraph should not be construed to mean that SRFI > 128 or 162 should export the new identifiers — that only if the bindings in > 128

SRFI 228 final read-through

I was just re-reading SRFI 228 in preparation for finalization when I came across this paragraph, which hadn't caught my attention originally, but which a recent discussion about SRFI versioning on the SRFI 162 mailing list made me think of i